NGHIÊN CỨU VÀ TRIỂN KHAI CÔNG NGHỆ AUTOSCALING TRÊN NỀN TẢNG KUBERNETES

Đồ Án Tốt Nghiệp về NGHIÊN CỨU VÀ TRIỂN KHAI CÔNG NGHỆ AUTOSCALING TRÊN NỀN TẢNG KUBERNETES Chương này sẽ trình bày về kiến trúc, chức năng của Kubernetes và các khái niệm trong Kubernetes. Đây là các kiến thức nền tảng của Kubernetes, giúp chúng ta hiểu các bộ phận cấu thành và cách làm việc của Kubernetes.

BỘ GIÁO DỤC VÀ ĐÀO TẠO BỘ NÔNG NGHIỆP VÀ PTNT

TRƯỜNG ĐẠI HỌC THỦY LỢI

HỌ VÀ TÊN:

NGHIÊN CỨU VÀ TRIỂN KHAI CÔNG NGHỆ

AUTOSCALING TRÊN NỀN TẢNG KUBERNETES

ĐỒ ÁN TỐT NGHIỆP

HÀ NỘI, NĂM 2023

BỘ GIÁO DỤC VÀ ĐÀO TẠO BỘ NÔNG NGHIỆP VÀ PTNT

TRƯỜNG ĐẠI HỌC THỦY LỢI

HỌ VÀ TÊN:

NGHIÊN CỨU VÀ TRIỂN KHAI CÔNG NGHỆ

AUTOSCALING TRÊN NỀN TẢNG KUBERNETES

i

LỜI CAM ĐOAN

Tác giả xin cam đoan đây là Đồ án tốt nghiệp/ Khóa luận tốt nghiệp của bản thân tác giả Các kết quả trong Đồ án tốt nghiệp/Khóa luận tốt nghiệp này là trung thực, và không sao chép từ bất kỳ một nguồn nào và dưới bất kỳ hình thức nào Việc tham khảo các nguồn tài liệu (nếu có) đã được thực hiện trích dẫn và ghi nguồn tài liệu tham khảo đúng quy định

Tác giả ĐATN/KLTN

ii

LỜI CÁM ƠN

Sau hơn 5 năm học tập tại khoa Công nghệ thông tin trường Đại học Thủy Lợi,

em đã nhận được sự chỉ bảo và giúp đỡ của các thầy cô giáo và các bạn rất nhiều trong lĩnh vực học tập và cuộc sống

Đầu tiên, em xin chân thành cảm ơn các thầy cô giáo Trường Đại học Thủy Lợi

và đặc biệt là các thầy cô giáo khoa Công nghệ thông tin đã dạy cho em có được những kiến thức để phục vụ cho việc thực hiện đồ án Đặc biệt, trong 14 tuần làm đồ án, em đã được sự hướng dẫn nhiệt tình của Tiến sĩ, Giảng viên BM Kỹ thuật Máy tính và Mạng

Đỗ Trường Xuân, cùng với các thầy cô giáo Khoa Công Nghệ thông tin và Tiến sĩ Em xin gửi lời cảm ơn chân thành tới thầy cô đã giúp đỡ, bổ sung cho em những kiến thức, cho em những lời khuyên và sự góp ý để em có thể hoàn thành đồ án một cách nhanh chóng và hiệu quả nhất

Trong suốt thời gian học tập và hoàn thành đồ án em đã may mắn được thầy cô chỉ bảo, dìu dắt và được gia đình bạn bè quan tâm, động viên luôn bên cạnh và tạo mọi điều kiện thuận lợi để cho em có thể hoàn thành đồ án này Trong suốt quá trình làm đồ

án với đề tài “Nghiên cứu và triển khai công nghệ autoscaling trên nền tảng kubernetes”, em đã cố gắng hết sức để xây dựng và hoàn thiện công cụ một cách tốt

nhất, nhưng do kiến thức còn hạn chế, thời gian làm đồ án có hạn và kinh nghiệm thực

tế chưa có nên cũng không thể tránh được những sai sót Vì thế em rất mong nhận được

sự thông cảm của các thầy cô giáo và các bạn Em rất mong nhận được sự góp ý của các thầy cô và các bạn để ứng dụng của em trở nên hoàn thiện hơn Một lần nữa, em xin chân thành cảm ơn thầy cô giáo, bạn bè và gia đình đã giúp đỡ em trong suốt thời gian qua

Em xin chân thành cảm ơn!

iii

MỤC LỤC

DANH MỤC CÁC HÌNH ẢNH v

DANH MỤC BẢNG BIỂU vi

DANH MỤC CÁC TỪ VIẾT TẮT VÀ GIẢI THÍCH CÁC THUẬT NGỮ vii

CHƯƠNG 1 GIỚI THIỆU 1

1.1 Tổng quan về điện toán đám mây 1

1.1.1 Điện toán đám mây là gì? 1

1.1.2 Những lợi ích của “Điện toán đám mây 2

1.1.3 Các công nghệ ảo hóa 3

1.2 Sự khác biệt VM(Virtual machine) và Container 4

1.2.1 Virtual machine là gì? 4

1.2.2 Container là gì? 6

1.2.3 So sánh VM và Container 7

1.3 Các nền tảng quản lý container 8

1.3.1 Kubernetes 8

1.3.2 Docker 9

1.3.3 Mesos 9

1.4 Tổng quan về Autoscaling 10

1.4.1 Auto Scaling là gì? 10

1.4.2 Lợi ích của Autoscaling 10

1.4.3 Các phương thức Scaling 11

1.4.4 Những tham số đầu vào để thực hiện AutoScaling 13

CHƯƠNG 2 KIẾN TRÚC KUBERNETES 14

2.1 Chức năng của Kubernetes 14

2.2 Kiến trúc Kubernetes 18

2.2.1 Master Node 19

2.2.2 Worker Node 20

2.3 Các khái niệm trong Kubernetes 21

2.3.1 Pod 21

2.3.2 Node 22

2.3.3 Service (svc) 23

iv

2.3.4 Deployment và ReplicaSet 25

2.3.5 Label và Selector trong Kubernetes 26

2.3.6 NameSpace 26

CHƯƠNG 3 GIẢI PHÁP AUTOSCALING 27

3.1 Horizontal Autoscaling 27

3.1.1 Quá trình Autoscaling 28

3.1.2 Thu thập metrics 28

3.1.3 Tính toán số lượng Pod cần thiết 29

3.1.4 Cập nhật trường replicas 31

3.1.5 Scale theo các chỉ số 32

3.1.6 Quản lý Pod mới trong Autoscaling 38

3.2 Vertical Autoscaling 52

3.2.1 Các thành phần của VPA 53

3.2.2 Update Policy 54

3.2.3 Thuật toán 55

3.3 Multidimensional Autoscaling 56

CHƯƠNG 4 CẤU HÌNH VÀ DEMO 59

4.1 Kịch bản triển khai 59

4.2 Triển khai hạ tầng 64

4.2.1 Triển khai cụm 64

4.2.2 Triển khai ứng dụng 64

4.3 Triển khai cái giải pháp Autoscaling 65

4.3.1 Triển khai Horizontal Pod Autoscaling 65

4.3.2 Triển khai Vertical Pod Autoscaling 68

v

DANH MỤC CÁC HÌNH ẢNH

Hình 2.1: Các Load Balancing có thể thực hiện tăng giảm số lượng Replicas 14

Hình 2.2: Các container được điều phối tự động 15

Hình 2.3: K8s tự động phân tỷ lệ các Kubernetes cluster 16

Hình 2.4: Self-healing giúp tự động khôi phục các service khi node xảy ra lỗi 17

Hình 2.5: Sử dụng container image trong kiến trúc microservices 18

Hình 2.6: Kiến trúc Kubernetes 18

Hình 2.7: Pod trong Kubernetes 22

Hình 2.8: Node trong Kubernetes 23

Hình 2.9: Service và Pod trong Kubernetes 24

Hình 2.10: Mô hình Deployment và ReplicaSet 25

Hình 2.11: Mối quan hệ giữa Deployment, ReplicaSet và Pod trong Kubernetes 26

Hình 2.12: Cơ chế lựa chọn Label Selector 26

Hình 2.13: NameSpace trong Kubernrtes 27

Hình 3.1: Mô hình Horizontal Pod Autoscaler 27

Hình 3.2: Quy trình thu thập Metrics 29

Hình 3.3: Horizontal Pod Autoscaling tính toán với nhiều metric 31

Hình 3.4: Horizontal Pod Autoscaling cập nhật trường replicas 32

Hình 3.5: Node Affinity 42

Hình 3.6: Preferred Node affinity 46

Hình 3.7: Pod affinity 49

Hình 3.8:Kiến trúc Vertical Autoscaling 52

Hình 3.9: Quy trình Update Policy 54

Hình 3.10: Biểu đồ quá trình VPA 56

Hình 4.1: Màn hình đăng nhập 59

Hình 4.2: Màn hình đăng ký 60

Hình 4.3: Màn hình nạp tiền 61

Hình 4.4: Màn hình rút tiền 62

Hình 4.5: Kịch bản triển khai 63

Hình 4.6: Trước khi scaling 67

Hình 4.7: Sau khi scaling 67

Hình 4.8: Các pod mới được tạo ra để giảm tải cho các pod đã tồn tại 68

vi

DANH MỤC BẢNG BIỂU

Bảng 3.1: Công thức tính số replicas đơn giản 30

Bảng 3.2: Công thức lựa chọn số replicas với nhiều metric 30

Bảng 3.3: Deployment.yaml khi scale theo CPU 32

Bảng 3.4: HPA.yaml khi scale theo CPU 33

Bảng 3.5: Kết quả HPA khi chưa thu thập dữ liệu 34

Bảng 3.6: Kết quả HPA khi đã thu thập dữ liệu 35

Bảng 3.7: Kiểm tra dữ liệu deployment 35

Bảng 3.8: Deployment.yaml khi scale theo memory 36

Bảng 3.9: Deployment.yaml khi scale theo pqs 37

Bảng 3.10: Cấu hình VPA theo số lượng request 38

Bảng 3.11: Cấu hình pod sử dụng Node Selector 39

Bảng 3.12: Câu lệnh để đánh label của node 40

Bảng 3.13: Cấu hình pod sử dụng Node Affinity 40

Bảng 3.14: Lấy thông tin các node 43

Bảng 3.15: Tạo label cho node 43

Bảng 3.16: Cấu hình pod sử dụng Node Affinity chế độ preferred 44

Bảng 3.17: Câu lệnh để tạo pod database 47

Bảng 3.18: Cấu hình pod sử dụng Pod Affinity 47

Bảng 3.19: Trường TopologyKey 49

Bảng 3.20: Cấu hình pod sử dụng Pod anti-affinity 50

Bảng 3.21: File cấu hình VerticalPodAutoscaler 52

Bảng 3.22: File cấu hình Multidimensional Autoscaling 56

CNCF Cloud Native Computing Foundation

DNS Domain Name System

DR Disaster Recovery

ĐATN Đồ án tốt nghiệp

HĐH Hệ điều hành

HPA Horizontal Pod Autoscaling

IEEE Institute of Electrical and Electronics Engineers

IP Internet Protocol

KLTN Khóa luận tốt nghiệp

LVTN Luận văn tốt nghiệp

VMM Virtual Machine Monitor

VPA Vertical Pod Autoscaling

VPS Virtual Private Server

1

CHƯƠNG 1 GIỚI THIỆU

Chương đầu tiên này sẽ trình bày tổng quan về điện toán đám mây, Autoscaling, Vitual Machine và Container, các nền tảng quản lý Container Giúp chúng ta nắm rõ được các kiến thức cơ bản nhất

1.1 Tổng quan về điện toán đám mây

1.1.1 Điện toán đám mây là gì?

Điện toán đám mây (cloud computing): hay còn gọi là điện toán máy chủ ảo nơi các tính toán được “định hướng dịch vụ” và phát triển dựa vào Internet Cụ thể hơn, trong mô hình điện toán đám mây, tất cả các tài nguyên, thông tin, và phần mềm đều được chia sẻ

và cung cấp cho các máy tính, thiết bị, người dùng dưới dạng dịch vụ trên nền tảng một

hạ tầng mạng công cộng (thường là mạng Internet) Người dùng sử dụng dịch vụ như

cơ sở dữ liệu, website, lưu trữ, … trong mô hình điện toán đám mây không cần quan tâm đến vị trí địa lý cũng như các thông tin khác của hệ thống mạng đám mây - “điện toán đám mây trong suốt đối với người dùng” Người dùng cuối truy cập và sử dụng các ứng dụng đám mây thông qua các ứng dụng như trình duyệt web, các ứng dụng di động, hoặc máy tính cá nhân thông thường Hiệu năng sử dụng phía người dùng cuối được cải thiện khi các phần mềm chuyên dụng, các cơ sở dữ liệu được lưu trữ và cài đặt trên hệ thống máy chủ ảo trong môi trường điện toán đám mây trên nền của “data center” “Data center” là thuật ngữ chỉ khu vực chứa server và các thiết bị lưu trữ, bao gồm nguồn điện

và các thiết bị khác như rack, cables, …có khả năng sẵn sàng và độ ổn định cao Ngoài

ra còn bao gồm các tiêu chí khác như: tính module hóa cao, khả năng mở rộng dễ dàng, nguồn và làm mát, hỗ trợ hợp nhất server và lưu trữ mật độ cao Có 3 mô hình triển khai điện toán đám mây chính là public (công cộng), private (riêng), và hybrid (“lai” giữa đám mây công cộng và riêng) Đám mây công cộng là mô hình đám mây mà trên đó, các nhà cung cấp đám mây cung cấp các dịch vụ như tài nguyên, platform, hay các ứng dụng lưu trữ trên đám mây và public ra bên ngoài Các dịch vụ trên public cloud có thể miễn phí hoặc có phí Đám mây riêng thì các dịch vụ được cung cấp nội bộ và thường

là các dịch vụ kinh doanh, mục đích nhắm đến cung cấp dịch vụ cho một nhóm người

và đứng đằng sau firewall Đám mây “lai” là môi trường đám mây mà kết hợp cung cấp

2

các dịch vụ công cộ ng và riêng Ngoài ra còn có “community cloud” là đám mây giữa các nhà cung cấp dịch vụ đám mây Về mô hình cung cấp dịch vụ có 3 loại chính là IaaS – cung cấp hạ tầng như một service, PaaS – cung cấp Platform như một service, và SaaS – cung cấp software như một service [1]

1.1.2 Những lợi ích của “Điện toán đám mây

Một số lợi ích cơ bản và đặc trưng của hệ thống “Điện toán đám mây”:

• Tăng sự linh hoạt của hệ thống (Increased Flexibility): khi cần thêm hay bớt một hay vài thiết bị (storaged devices, servers, computers, …) chỉ cần mất vài giây

• Sử dụng tài nguyên theo yêu cầu (IT Resources on demand): tùy thuộc vào nhu cầu của khách hàng mà administrator setup cấu hình hệ thống cung cấp cho khách hàng

• Tăng khả năng sẵn sàng của hệ thống (Increased availability): các ứng dụng và dịch vụ được cân bằng động để đảm bảo tính khả dụng Khi một trong các hardware bị hư hỏng không làm ảnh hưởng đến hệ thống, chỉ suy giảm tài nguyên

hệ thống

• Tiết kiệm phần cứng (Hardware saving): mô hình truyền thống trong nhiều trường hợp cần một hệ thống riêng biệt cho mỗi tác vụ, dịch vụ Điều này gây ra lãng phí, trong mô hình “Điện toán đám mây”, các tài nguyên IT được quản lý

để đảm bảo sự không lãng phí này Cung cấp các dịch vụ với độ sẵn sàng gần như 100% (taking down services in real time)

• Trả theo nhu cầu sử dụng thực tế (Paying-as-you- go IT): mô hình “Cloud computing”, tích hợp với hệ thống billing để thực hiện việc tính cước dựa theo dung lượng người dùng đối với các tài nguyên như tốc độ CPU, dung lượng RAM, dung lượng HDD, …

Tóm lại, mô hình “Điện toán đám mây” đã khắc phục được 2 yếu điểm quan trọng của

mô hình truyền thống về “khả năng mở rộng (scalability)” và “độ linh hoạt (flexibility)” Các tổ chức cũng như công ty có thể triển khai ứng dụng và dịch vụ nhanh chóng, chi

3

phí giảm, và ít rủi ro Phần tiếp theo sẽ giới thiệu về ảo hóa – là công nghệ cốt lõi và được xem như là một bước đệm chuyển tiếp từ mô hình truyền thống sang CC [1]

1.1.3 Các công nghệ ảo hóa

1.1.3.1 Kernel mode và User mode

Kernel mode: đây là không gian được bảo vệ nơi mà “nhân” của HĐH xử lý và tương tác trực tiếp với phần cứng Một ví dụ điển hình cho Kernel mode là các drivers của thiết

bị Khi có sự cố thì hệ thống ngưng hoạt động và thông báo lỗi như ở windows sẽ hiển thị màn hình xanh khi có lỗi giao tiếp phần cứng User mode: đây là không gian nơi các ứng dụng chạy, ví dụ Office, MySQL, hay Exchange server Khi có sự cố ở các ứng dụng thì chỉ có các ứng dụng ngưng hoạt động mà không ảnh hưởng gì đến server [1]

1.1.3.2 Hypervisor

Tất cả các loại ảo hóa được quản lý bởi VMM (Virtual Machine Monitor) VMM về bản chất cũng được chia làm 2 loại là: VMM đóng vai trò như một phần mềm trung gian chạy trên HĐH để chia sẻ tài nguyên với HĐH Ví dụ: VMware workstation, Virtual

PC VMM đóng vai trò là một hypervisor chạy trên phần cứng Ví dụ: VMware ESXi, Hyper-V, Xen Hypervisor là một phần mềm nằm ngay trên phần cứng hoặc bên dưới HĐH nhằm mục đích cung cấp các môi trường tách biệt gọi là các phân vùng – partition Mỗi phân vùng ứng với mỗi máy ảo - VM có thể chạy các HĐH độc lập Hiện nay có 2 hướng tiếp cận hypervisor khác nhau (loại 2 – hypervisor VMM) với tên gọi: Monolithic

và Micro hypervisor [1]

1.1.3.3 Full-virtualization

Full- virtualization là công nghệ ảo hóa để cung cấp 1 loại hình máy ảo dưới dạng mô phỏng của 1 máy chủ thật với đầy đủ tất cả các tính năng bao gồm input/output operations, interrupts, memory access, … Tuy nhiên mô hình ảo hóa này không thể khai thác tốt hiệu năng khi phải thông qua một trình quản lý máy ảo (Virtual Machines monitor hay hypervisor) để tương tác đến tài nguyên hệ thống (mode switching) Vì vậy

sẽ bị hạn chế bớt 1 số tính năng khi cần thực hiện trực tiếp từ CPU Xen, VMWare workstation, Virtual Box, Qemu/KVM, và Microsoft Virtual Server hỗ trợ loại ảo hóa này [1]

4

1.1.3.4 Para-virtualization

Para-virtualization hay còn gọi là ảo hóa “một phần” là kỹ thuật ảo hóa được hỗ trợ và điều khiển bởi 1 hypervisor nhưng các Oss của guest thực thi các lệnh không phải thông qua Hypervisor (hay bất kỳ 1 trình quản lý máy ảo nào) nên không bị hạn chế về quyền hạn Tuy nhiên nhược điểm của loại ảo hóa này là các OS biết đang chạy trên 1 nền tảng phần cứng ảo và khó cấu hình cài đặt Ảo hóa Para -Virtualization được hỗ trợ bởi Xen, VMware, Hyper-V [1]

1.1.3.5 OS-level virtualization (Isolation)

OS level virtualization, còn gọi là containers Virtualization hay Isolation: là phương pháp ảo hóa mới cho phép nhân của hệ điều hành hỗ trợ nhiều instances được cách ly dựa trên một HĐH có sẵn cho nhiều users khác nhau, hay nói cách khác là tạo và chạy được nhiều máy ảo cách ly và an toàn (secure) dùng chung 1 HĐH Ưu điểm của ảo hóa này là bảo trì nhanh chóng nên được ứng dụng rộng rãi trong các lĩnh vực hosting OpenVZ, Virtuozzo, Linux-VServer, Solaris Zones, và FreeBSD Jails hỗ trợ lo ại ảo hóa này Một lưu ý là loại ảo hóa Isolation này chỉ tồn tại trên HĐH Linux Nếu ảo hóa chỉ là công nghệ nền tảng của CC thì việc triển khai CC trong thực tế dựa vào 2 giải pháp cơ bản sau: sử dụng các sản phẩm thương mại cho CC như của VMware, Microsoft (Hyper-V), hoặc các sản phẩm nguồn mở như Eucalyptus và OpenStack Phần kế sẽ trình bày về lợi ích của hướng tiếp cận triển khai CC dùng nguồn mở [1]

1.2 Sự khác biệt VM(Virtual machine) và Container

1.2.1 Virtual machine là gì?

Đây là giải pháp tuyệt vời khi chúng ta muốn chạy nhiều hệ điều hành trên một máy vào cùng một thời điểm Với giải pháp ảo này, toàn bộ hệ thống từ Phần cứng (RAM, CPU, HDD,…) cho đến hệ điều hành đều được “ảo hoá” Đem lại trải nghiệm sử dụng gần tương đương như một máy thật

Khi sức mạnh và công suất xử lý của máy chủ tăng lên; các ứng dụng baremetal không thể đáp ứng việc khai thác đa dạng nguồn tài nguyên Do đó, Virtual machine được sinh

ra Virtual machine được thiết kế bằng cách chạy phần mềm trên các máy chủ vật lý; để

5

mô phỏng một hệ thống phần cứng cụ thể Một trình ảo hóa – hypevisor là phần mềm; chương trình cơ sở hoặc phần cứng tạo ra và chạy các máy ảo Virtual machine Nó là phần nằm giữa phần cứng và máy ảo; cần thiết để ảo hóa máy chủ

Trong mỗi máy ảo chạy một hệ điều hành khách duy nhất Máy ảo với các hệ điều hành khác nhau có thể chạy trên cùng một máy chủ vật lý — máy ảo UNIX có thể nằm cùng với máy ảo Linux, v.v Mỗi máy ảo đều có các tệp nhị phân; thư viện và ứng dụng riêng

mà nó phục vụ; và máy ảo có thể có kích thước nhiều gigabyte [2]

Lợi ích của VM:

Ảo hóa máy chủ mang lại nhiều lợi ích; một trong những lợi ích lớn nhất là khả năng hợp nhất các ứng dụng vào một hệ thống duy nhất Đã qua rồi cái thời của một ứng dụng chạy trên một máy chủ Ảo hóa giúp tiết kiệm chi phí thông qua việc loại bỏ footprint; cung cấp máy chủ nhanh hơn và cải thiện khả năng khôi phục sau thảm họa (DR); vì phần cứng trang DR không còn phải phản chiếu trung tâm dữ liệu chính Việc sử dụng nhiều hơn trên các máy chủ lớn hơn, nhanh hơn đã giải phóng các máy chủ không sử dụng; sau đó được sử dụng lại cho QA, hoặc làm thiết bị phòng thí nghiệm [2]

Hạn chế:

Nhưng phương pháp này đã có những hạn chế của nó Mỗi máy ảo bao gồm một hình ảnh của hệ điều hành riêng biệt; bổ sung thêm chi phí trong bộ nhớ và những vấn đề đã được lưu trữ Vấn đề này làm tăng thêm sự phức tạp cho tất cả các giai đoạn của vòng đời phát triển phần mềm — từ phát triển và thử nghiệm; đến sản xuất và khôi phục thảm họa Cách tiếp cận này cũng hạn chế nghiêm trọng tính di động của các ứng dụng giữa các đám mây công cộng; đám mây riêng và các trung tâm dữ liệu truyền thống

Hơn nữa, việc phải ảo hoá này làm tiêu tốn một khoản tài nguyên không hề nhỏ của hệ điều hành chủ (host system) Muốn chạy được dịch vụ, chúng ta phải khởi động cả hệ điều hành ảo Do đó, thời gian startup, stop, hay restart tốn ít nhất phải vài phút Từ những điểm yếu trên; công nghệ Container được sinh ra như là một giải pháp hoàn hảo

để chạy các dịch vụ trên máy ảo; mà tiêu tốn tài nguyên ít nhất, đồng thời có hiệu suất cao nhất [2]

6

1.2.2 Container là gì?

Ảo hoá Container còn có cách gọi khác là "ảo hoá mức hệ điều hành" (operating system virtualization) Chúng ta không ảo hoá cả phần cứng, hệ điều hành nữa mà chỉ ảo hoá môi trường Các dịch vụ trong Container vẫn chạy chung hệ điều hành chủ ở phía dưới, chung Kernel nhưng môi trường chạy của các dịch vụ thì luôn được đảm bảo hoàn toàn độc lập với nhau Thuật ngữ "Container" ở đây được hiểu là khái niệm đóng gói Một Container chứa đầy đủ application và tất các các thành phần phụ thuộc như: Các file Bins, các thư viện kèm theo để đảm bảo các ứng dụng có thể chạy độc lập trong container

đó Như vậy mỗi Container ở đây được coi như một "máy ảo" mini [2]

Lợi ích của ảo hóa Container:

Các container nằm trên máy chủ vật lý và hệ điều hành chủ của nó — ví dụ: Linux hoặc Windows Mỗi vùng chứa chia sẻ Host OS kernel và thường là các tệp nhị phân và thư viện Các thành phần được chia sẻ ở chế độ “chỉ đọc” Do đó, các vùng chứa đặc biệt

“nhẹ” — chúng chỉ có kích thước megabyte và chỉ mất vài giây để khởi động và vài phút đối với máy ảo Đây cũng là điểm mạnh lớn nhất của Container Với một máy tính cấu hình bình thường; nếu chạy máy ảo VM truyền thống, chúng ta chỉ chạy được khoảng vài cái; thì ở đây, nếu chạy bằng Contaner, chúng ta có thể chạy đến vài chục đến vài trăm cái [2]

Ngoài ra, Container cũng giảm chi phí quản lý Bởi vì chúng chia sẻ một hệ điều hành chung; chỉ một hệ điều hành duy nhất cần được bảo trì và cung cấp cho các bản sửa lỗi, bản vá, v.v Khái niệm này tương tự như những gì chúng ta trải nghiệm với máy chủ hypervisor: ít điểm quản lý hơn; nhưng miền lỗi cao hơn một chút Chúng ta có thể tự tạo ra một Container từ một mẫu có sẵn, cài đặt môi trường; và sau đó lưu trạng thái lại như một “image”; triển khai “image” này đến bất kỳ chỗ nào mà chúng ta muốn Tóm lại, container có trọng lượng nhẹ hơn và dễ di chuyển hơn VM [2]

Hạn chế:

Điểm yếu duy nhất của công nghệ này, đó là việc giới hạn của ảo hóa hệ điều hành Vì container sử dụng chung kernel với hệ điều hành chủ; cho nên, chúng ta chỉ có thể ảo hóa được hệ điều hành mà hệ điều hành chủ hỗ trợ mà thôi Ví dụ: nếu HĐH chủ là

di động của container khiến chúng trở thành một công cụ khác giúp hợp lý hóa việc phát triển phần mềm [2]

1.2.3 So sánh VM và Container

Bảng 1.1: So sánh VM và Container

Tài nguyên (resource) Mọi thứ đều bị giới hạn bởi

phần cứng ảo

Process trong container sử dụng trực tiếp tài nguyên thật, nhưng HĐH có thể quy định mỗi process một mức giới hạn tài nguyên khác nhau (hoặc không giới hạn)

Thực thi (execution) HĐH thật → HĐH ảo →

HĐH ảo chạy phần mềm

(Đối với VPS, Hypervisor type 1 thay thế cho HĐH thật)

HĐH thật chạy phần mềm

Sự tối ưu (performance) Phần cứng thật phải gánh

cả một HĐH ảo Từ khi máy tính khởi động lên, cho tới khi sử dụng được

Phần mềm thật chạy trên phần cứng thật Tốc độ khởi động gần như một phần mềm bình thường

8

phần mềm rất mất thời gian

Tính bảo mật (Security) Phần mềm có mã độc có

thể ảnh hưởng tới tài nguyên của process khác trong cùng VM Process trong môi trường ảo không thể truy xuất tới môi trường của HĐH chủ

Process trong cùng container vẫn có thể ảnh hưởng tới nhau Nhưng thông thường mỗi container chỉ nên chạy một process Process khác container không thể gây ảnh hưởng cho nhau Process trong môi trường

ảo không thể truy xuất tới môi trường của HĐH chủ [3]

9

1.3.2 Docker

Docker là một nền tảng mã nguồn mở để xây dựng, triển khai và quản lý các ứng dụng được containers (trên nền tảng ảo hóa) Docker cung cấp cách để building, deloying và running ứng dụng dễ dàng bằng cách sử dụng containers

Docker là phần mềm tạo ra các container tương tự Kubernetes và một công cụ quản lý container là Swarm Swarm phổ biến vì nó là một giải pháp tự nhiên trong chính Docker

để quản lý các container Nó quản lý bằng cách sử dụng các Docker daemon trong một cluster để biến một nhóm Docker engine thành một Docker engine duy nhất nhờ sử dụng Docker API Giải pháp phổ biến này cho phép tích hợp dọc các quá trình từ trên xuống dưới Kiểu tích hợp này có thể vượt trội hơn lợi ích của việc sử dụng một dịch vụ bổ sung để xử lý việc bảo trì container

Tuy nhiên, nếu đang tìm kiếm sự tự động hóa xử lý quản lý tài nguyên trong một công

cụ để từ đó giải phóng nhóm DevOps để phát triển các giải pháp cho khách hàng, thì sử dụng Kubernetes có thể là một giải pháp tốt hơn Mặc dù các công cụ Docker cho phép kiểm soát thủ công chỉ với chi phí của tự động hóa, nhưng khi nhìn vào sự tích hợp đầy

đủ, Kubernetes là lựa chọn phổ biến hơn trong lĩnh vực này [4]

1.3.3 Mesos

Apache Mesos là một công cụ nguồn mở khác được sử dụng để quản lý các container Công cụ này là một giải pháp nguồn mở để quản lý container vượt trội hơn Kubernetes nhưng đã không giữ được vị trí này lâu Mặc dù vậy, nó vẫn là một công cụ phổ biến dựa trên tuổi thọ của nó trên thị trường kèm theo tài liệu có sẵn Apache Mesos cũng đã chứng minh tính hữu dụng của nó bằng cách nhân rộng lên đến hàng chục nghìn nodes trong khi nâng cấp một cách dễ dàng và không gây gián đoạn

Apache hoạt động với cả Docker và AppC nhờ có các API cho phép phát triển các ứng dụng phân tán Phần mềm quản lý container này cho phép độc lập tùy chỉnh CPU, bộ nhớ, cổng, đĩa và các tài nguyên khác Nhờ đó, người dùng có thể quản lý container và xác định tài nguyên nào có thể được chia sẻ giữa chúng một cách linh hoạt hơn

Apache Mesos thực hiện điều này bằng cách cho phép master daemon quản lý các agent daemon Mỗi agent daemon nằm trên một cluster node chạy một tác vụ Nhờ vậy công

10

nghệ có khả năng kiểm soát chi tiết đối với các tài nguyên đang được sử dụng bằng cách tạo ra các ưu đãi tài nguyên giữa agent Apache sử dụng một scheduler và một executor trong khung của nó để chạy quá trình này [4]

1.4 Tổng quan về Autoscaling

1.4.1 Auto Scaling là gì?

Auto Scaling là một giải pháp có khả năng thu hẹp hoặc mở rộng số lượng tài nguyên máy tính được sử dụng để phân phối cho các ứng dụng một cách tự động trong khoảng thời gian bất kỳ tùy theo từng nhu cầu sử dụng của người dùng

Trước khi công nghệ điện toán đám mây được ra đời, việc mở rộng website hay máy chủ đều là vấn đề lớn gây khó khăn cho người quản trị Trong môi trường lưu trữ chuyên dụng, tài nguyên phần cứng bị hạn chế sẽ gây ra những ảnh hưởng nặng nề cho website thậm chí là sập hiệu suất và đánh mất dữ liệu

Sự ra đời của công nghệ điện toán đám mây được xem như bước ngoặt giúp giải quyết vấn đề phân bố tài nguyên máy tính Từ đó, việc mở rộng thêm tài nguyên đã không còn quá khó khăn Bạn có thể khởi chạy các tài nguyên, sử dụng và ngưng sử dụng chúng theo nhu cầu của mình [5]

1.4.2 Lợi ích của Autoscaling

- Đối với các công ty chạy nền tảng web server của chính công ty, auto scaling cho phép một số server ngừng hoạt động trong thời gian thấp điểm, giúp tiết kiệm tiền điện, chi phí vận hành

- Đối với các công ty chạy hạ tầng cơ sở trên đám mây, auto scaling đồng nghĩa với chi phí thấp bởi hầu hết các nhà cung cấp dịch vụ đám mây tính phí dựa trên tổng mức sử dụng chứ không dựa trên công suất tối đa

- Ngay cả đối với các công ty không thể giảm tổng dung lượng tài nguyên chạy hoặc tài nguyên thanh toán trong một thời điểm bất kỳ, auto scaling sẽ cho phép công ty chạy các công việc ít có độ nhạy cảm về thời gian trên các máy đã được auto scaling trong thời gian lượng traffic thấp

11

- Các giải pháp auto scaling cũng có thể được sử dụng để thay thế các đối tượng (không đảm bảo) unhealthy và do đó phần nào giúp chống lại các lỗi phần cứng, lỗi mạng và lỗi ứng dụng

- Auto scaling có thể mang lại tỷ lệ uptime tốt hơn và tính sẵn sàng cao hơn trong trường hợp khối lượng công việc thay đổi đột ngột và bất ngờ

Auto scaling không giống với chu kỳ sử dụng máy chủ theo ngày, tuần hoặc theo năm

mà tương thích với các trường hợp sử dụng thực tế, và do đó làm giảm nguy cơ có quá

ít hoặc quá nhiều máy chủ phục vụ truyền tải lưu lượng

Ví dụ: lưu lượng truy cập thường có xu hướng thấp hơn vào nửa đêm, giải pháp mở rộng tĩnh (static scaling) có thể lên lịch để một số máy chủ ở trạng thái sleep vào ban đêm, nhưng như vậy có thể dẫn đến tình trạng downtime vào ban đêm khi số lượng người sử dụng Internet đột ngột tăng vào ban đêm (ví dụ: do một sự kiện hoặc tin tức chấn động nào đó đang lan truyền rộng rãi tại thời điểm nửa đêm) Trong những tình huống như thế này, auto scaling sẽ xử lý lưu lượng tăng đột biến tốt hơn rất nhiều [6]

1500 khách truy cập mỗi giờ thì trải nghiệm của họ tại trang web sẽ giảm Máy chủ ảo

sẽ không có đủ tài nguyên để xử lý một cách hoàn hảo Khi ấy, vấn đề đặt ra là bạn cần

mở rộng quy mô máy chủ: tăng kích thước của máy chủ bằng cách thêm CPU, bộ nhớ

bổ sung, dung lượng ổ đĩa…

Vertical scaling đạt được bằng cách thêm tài nguyên bổ sung dưới dạng CPU hoặc bộ nhớ vào máy hiện có Bằng cách đó, máy có thể phục vụ thêm khách hàng hoặc thực hiện các tác vụ tính toán nhanh hơn để bạn có thể đi từ máy chủ trung bình (medium server) đến máy chủ lớn (large server) hay thậm chí đến máy chủ cực lớn (extra large

12

server) và khi làm như vậy, bạn có thể đối phó với sự gia tăng không ngừng số lượng người dùng Máy chủ ảo càng lớn hoặc instance càng lớn thì càng có nhiều người dùng nhưng nhìn chung nó có một số hạn chế thực sự quan trọng.Khi chỉ có một instance hoặc một máy chủ ảo duy nhất lưu trữ ứng dụng, điều đó cũng có nghĩa là rủi ro tăng lên đáng

kể

Một vấn đề khác là có những giới hạn đối với việc một instance có thể lớn đến mức nào Bạn có thể tiếp tục thêm CPU, bộ nhớ bổ sung, nhưng đến một lúc nào đó chúng sẽ đạt đến giới hạn Quy mô càng lớn, bạn càng tốn nhiều phí cho mỗi đơn vị năng lực bổ sung Trong trường hợp máy chủ vật lý, bạn cần tắt nguồn máy chủ và thực hiện thay đổi phần cứng máy chủ đó Nếu đó là một máy chủ ảo, bạn thường có thể thay đổi tài nguyên nhưng nó vẫn yêu cầu khởi động lại Điều này gây gián đoạn cho trải nghiệm của người dùng [7]

bị giới hạn kích thước của quy mô ảo và nó thực sự có thể mở rộng đến mức gần vô hạn nhưng nó yêu cầu hỗ trợ từ ứng dụng để mở rộng hiệu quả

Các nhược điểm của Vertical scaling gần như đều được khắc phục khi sử dụng Horizontal scaling:

• Phân tán rủi ro lên nhiều thành phần nhỏ thay vì lên một khối duy nhất

• Có thể thực hiện Scaling thường xuyên mà không bị ngừng hoạt động vì bạn chỉ thêm tài nguyên bổ sung chứ không thay đổi tài nguyên hiện có nên bản chất là không phá

vỡ việc cung cấp dịch vụ hiện tại của mình

• Chi phí rẻ hơn: Sử dụng 10 máy chủ có kích thước bằng 1/10 kích thước của máy chủ lớn duy nhất thì 10 máy chủ đó có giá rẻ hơn so với 1 máy chủ lớn nhất

1.4.4 Những tham số đầu vào để thực hiện AutoScaling

Cần cung cấp những tham số, số liệu hữu ích nhất để biết khi nào mở rộng và thêm một máy chủ khác hoặc giảm quy mô bằng cách chấm dứt một máy chủ đó là dựa vào thông

số sử dụng CPU, sử dụng bộ nhớ hoặc sử dụng mạng Các tham số truyền vào bao gồm:

• Sử dụng CPU (%)

• Sử dụng bộ nhớ (%)

• Bộ nhớ được sử dụng (MB)

• Bộ nhớ khả dụng (MB)

• Sử dụng không gian đĩa (%)

• Dung lượng đĩa được sử dụng (GB)

• Dung lượng đĩa trống (GB)

• Và nhiều thông số khác [8]

14

CHƯƠNG 2 KIẾN TRÚC KUBERNETES

Chương này sẽ trình bày về kiến trúc, chức năng của Kubernetes và các khái niệm trong Kubernetes Đây là các kiến thức nền tảng của Kubernetes, giúp chúng ta hiểu các bộ phận cấu thành và cách làm việc của Kubernetes

2.1 Chức năng của Kubernetes

K8s quản lý nhiều Docker host bằng cách tạo các container cluster (cụm container) Ngoài ra, khi chạy một container trên Kubernetes, việc triển khai replicas (tạo các bản sao giống nhau) có thể đảm bảo cân bằng tải (load balancing) tự động và tăng khả năng chịu lỗi Đồng thời nhờ có cân bằng tải mà cũng có thể thực hiện autoscaling - tự động tăng giảm số lượng replicas

Hình 2.1: Các Load Balancing có thể thực hiện tăng giảm số lượng Replicas

Docker host còn gọi là Node Khi sắp xếp các container vào các Node này, có các dạng workload như "Sử dụng Disk I/O nhiều" và "sử dụng băng thông cao", và "Disk là SSD"

và "CPU xung nhịp cao cao" Tùy thuộc vào loại máy chủ Docker và loại workload, K8s

có thể tự ý thức được việc affinity hay anti-affinity để lập lịch cho hợp lý

15

Hình 2.2: Các container được điều phối tự động

Trong các trường hợp không cụ thể khác, scheduling sẽ được thực hiện dựa trên tình trạng CPU và bộ nhớ trống, do đó người dùng không cần quản lý việc đặt container vào Docker host nào Ngoài ra, nếu tài nguyên không đủ, k8s cũng sẽ tự động phân tỷ lệ các Kubernetes cluster

16

Hình 2.3: K8s tự động phân tỷ lệ các Kubernetes cluster

Với khả năng chịu lỗi cao, Kubernetes thực hiện giám sát container theo tiêu chuẩn Trong trường hợp có sự cố bất ngờ, một container nào đó bị dừng thì sẽ thực hiện self-healing bằng cách khởi động lại container đó Self-healing là một trong những khái niệm quan trọng trong k8s giúp tự động khôi phục các service khi node xảy ra lỗi, bị die, hoặc

bị di chuyển đi

Bên cạnh việc giám sát, K8s cũng có thể thiết lập healthcheck với các tập lệnh HTTP/TCP/shell

17

Hình 2.4: Self-healing giúp tự động khôi phục các service khi node xảy ra lỗi

Khi thực hiện auto scaling, nếu xảy ra vấn đề về endpoint đến container Trong trường hợp sử dụng máy ảo, với việc đặt load balancing, endpoint được cấp là VIP

K8s cũng có chức năng như vậy gọi là Service cung cấp load balancing cho một nhóm container cụ thể Ngoài việc tự động thêm và xóa tại thời điểm scale, nó tự động ngắt kết nối trong trường hợp container bị lỗi Việc tự động cách ly trước khi rolling updates container, cho thấy K8s có khả năng quản lý các endpoint với SLA cao

Với kiến trúc microservices, để triển khai và sử dụng container image tạo ra tương ứng cho mỗi chức năng sẽ cần đến Service discovery

18

Hình 2.5: Sử dụng container image trong kiến trúc microservices

Như vậy, để sử dụng Docker trong môi trường production mà không sử dụng công cụ điều phối như Kubernetes, người dùng sẽ cần phải tự tạo các chức năng được đề cập phía trên Nhưng với Kubernetes, chúng ta có thể tận dụng cơ chế tự động hóa của công cụ này [9]

2.2 Kiến trúc Kubernetes

Một kiến trúc Kubernetes sẽ bao gồm các thành phần dưới đây:

Hình 2.6: Kiến trúc Kubernetes

19

Master Node

Được xem như cơ quan đầu não trong kiến trúc Kubernetes, Master Node có vai trò quan trọng trong việc điều phối và quản lý các container và các node có trong cụm Kubernetes Để giúp gia tăng khả năng xử lý các sự cố và tính sẵn sàng của Kubernetes, một cluster có thể bao gồm nhiều Master node cùng tồn tại như Kubernetes API Server, ectd, scheduler, controller manager và cloud controller manager

Worker/Slave Node

Worker/Slave Node là các server vận hành các ứng dụng được Master node điều khiển Worker Node được thiết lập với khả năng chạy được trên tất cả các nút thuộc Kubernetes với nhiệm vụ quản lý và thông báo tình trạng các Pods cho Master node Các thành phần chính có trong Worker Node bao gồm Kubelet, Kubernetes Service Proxy và Container Runtime

Các Addons

Các Addons (service và pod) là thành phần còn lại của Kubernetes giữ vai trò thực hiện các chức năng của cluster bao gồm Container Resource Monitoring, DNS Server, Cluster-level Logging… [10]

2.2.1 Master Node

Master node là nơi đảm nhiệm tất cả các tác vụ quản trị chịu trách nhiệm quản lý cụm Kubernetes Có thể có nhiều hơn một master node trong cụm để tăng khả năng chịu lỗi Việc có nhiều hơn một master node giúp cụm kubernetes có tính sẵn sàng cao, trong đó một trong số chúng sẽ là master node mà chúng ta thực hiện tất cả các tác vụ Để quản

lý trạng thái cụm, nó sử dụng etcd trong đó tất cả các node master kết nối với nó Một nút chính bao gồm 5 thành phần:

• etcd cluster – Là một kho lưu trữ giá trị khóa phân tán, đơn giản được sử dụng để

lưu trữ dữ liệu cụm Kubernetes (chẳng hạn như số lượng pod, trạng thái của chúng, namespace, v.v.), các API object và chi tiết service discovery Nó chỉ có thể truy cập được từ API Server vì lý do bảo mật etcd bật thông báo cho cụm về các thay đổi cấu

20

hình với sự trợ giúp của những watcher Thông báo là các yêu cầu API trên mỗi node của cụm etcd để kích hoạt cập nhật thông tin trong bộ nhớ của node

• kube-apiserver – Kubernetes API là thực thể quản lý trung tâm nhận tất cả các yêu

cầu REST để sửa đổi (đối với pod, service, bộ sao chép / bộ điều khiển và những thứ khác), đóng vai trò là giao diện người dùng cho cụm Ngoài ra, đây là thành phần duy nhất giao tiếp với cụm etcd, đảm bảo dữ liệu được lưu trữ trong etcd và phù hợp với chi tiết dịch vụ của các pod được triển khai

• kube-controller-manager – Là tiến trình chạy các controller để xử lý các

background task của Cluster, giúp căn chỉnh cluster vào đúng với trạng thái đã khai báo (declare) ở Resource

• cloud-controller-manager – Chịu trách nhiệm quản lý các tiến trình của bộ điều

khiển với sự phụ thuộc vào nhà cung cấp cloud (nếu có) Ví dụ: khi một bộ điều khiển cần kiểm tra xem một node đã được kết thúc hoặc thiết lập các route, load-balancer hoặc volume trong cơ sở hạ tầng cloud hay chưa, tất cả những gì được xử lý bởi cloud-controller-manager

• kube-Scheduler – Giúp lập lịch các pod trên các node khác nhau dựa trên việc sử

dụng tài nguyên Nó đọc các yêu cầu hoạt động của dịch vụ và lên lịch trên node phù hợp nhất Ví dụ: nếu ứng dụng cần 1GB bộ nhớ và 2 core CPU, thì các nhóm cho ứng dụng đó sẽ được lên lịch trên một node có tài nguyên phù hợp Bộ lập lịch chạy mỗi khi có nhu cầu lập lịch nhóm Bộ lập lịch phải biết tổng tài nguyên hiện có cũng như tài nguyên được phân bổ cho khối lượng công việc hiện có trên mỗi node [11]

2.2.2 Worker Node

Worker node là một máy chủ (máy ảo) chạy các ứng dụng sử dụng các Pod được điều khiển bởi Master node Trên worker node, các pod được lập lịch Để truy cập các ứng dụng từ thế giới bên ngoài, chúng ta kết nối với chúng qua các node

Các thành phần của worker node là:

• kubelet – Là service chính trên mỗi node, thường xuyên nhận các thông số của pod

mới hoặc được sửa đổi (chủ yếu thông qua kube-apiserver) và đảm bảo rằng các pod

và container của chúng không có vấn đề gì và chạy ở trạng thái mong muốn Thành phần này cũng báo cáo cho master về tình trạng của node nơi mà nó đang chạy

21

• kube-proxy – một dịch vụ proxy chạy trên mỗi worker node để xử lý vấn đề về mạng

trên mỗi worker node và expose các port của service với bên ngoài internet Nó thực hiện chuyển tiếp yêu cầu đến các pod / container chính xác trên các network bị cô lập khác nhau trong một cụm [11]

2.3 Các khái niệm trong Kubernetes

2.3.1 Pod

Pod là một khái niệm trừu tượng của Kubernetes, đại diện cho một nhóm gồm một hoặc nhiều ứng dụng containers (ví dụ như Docker) và một số tài nguyên được chia sẻ cho các containers đó Những tài nguyên đó bao gồm:

• Lưu trữ được chia sẻ, dưới dạng Volumes

• Kết nối mạng, như một cluster IP duy nhất

• Thông tin về cách chạy từng container, chẳng hạn như phiên bản container image hoặc các ports cụ thể để sử dụng

Một Pod mô phỏng một "máy chủ logic" dành riêng cho ứng dụng và có thể chứa các ứng dụng containers khác nhau được liên kết tương đối chặt chẽ Ví dụ, một Pod có thể bao gồm cả container với ứng dụng Node.js của bạn cũng như một container khác cung cấp dữ liệu hiển thị bởi webserver của Node.js Các containers trong một Pod chia sẻ một địa chỉ IP và port space, chúng luôn được đặt cùng vị trí, cùng lên lịch trình, và chạy trong ngữ cảnh được chia sẻ trên cùng một Node

Pods là các đơn vị nguyên tử trên nền tảng Kubernetes Khi chúng tôi tạo một kịch bản triển khai (Deployment) trên Kubernetes, kịch bản triển khai đó tạo ra các Pods với các containers bên trong chúng (trái ngược với việc tạo các containers trực tiếp) Mỗi Pod được gắn với Node nơi nó được lên lịch trình, và tiếp tục ở đó cho đến khi chấm dứt (theo chính sách khởi động lại) Trong trường hợp có lỗi ở Node, các Pods giống nhau được lên lịch trình trên các Nodes có sẵn khác trong cluster [12]

Mỗi Node ở Kubernetes chạy ít nhất:

• Kubelet, một quy trình chịu trách nhiệm liên lạc giữa Kubernetes Master và Node; quản lí các Pods và các containers đang chạy trên cùng một máy

• Một container runtime (như Docker) chịu trách nhiệm lấy container, giải nén container và chạy ứng dụng Các containers chỉ nên được lên lịch trình cùng nhau trong một Pod duy nhất nếu chúng được liên kết chặt chẽ

• Các containers chỉ nên được lên lịch trình cùng nhau trong một Pod duy nhất nếu chúng được liên kết chặt chẽ và cần chia sẻ tài nguyên như disk [12]

• ClusterIP: Service chỉ có địa chỉ IP cục bộ và chỉ có thể truy cập được từ các thành phần trong cluster Kubernetes

• NodePort: Service có thể tương tác qua Port của các worker nodes trong cluster

• LoadBlancer: Service có địa chỉ IP public, có thể tương tác ở bất cứ đâu

• ExternalName: Ánh xạ service với 1 DNS Name [13]

24

Hình 2.9: Service và Pod trong Kubernetes

25

Tiến trình Kube Proxy sử dụng thông tin có trong Service để cấu hình các rule iptables thích hợp trên mỗi Node để điều phối lượng truy cập từ người dùng cần truy cập Service được định tuyến vào đúng Pod phù hợp [14]

2.3.4 Deployment và ReplicaSet

Hình 2.10: Mô hình Deployment và ReplicaSet

Deployment trong Kubernetes cho phép quản lý vòng đời của các Pod và một Resource liên quan gọi là ReplicaSet Deployment chứa đặc tả (specification) cho một Pod và các thông tin thêm, như số lượng Pod để chạy Deployment trong Kubernetes cho phép cập nhật một ứng dụng đang chạy mà không có downtime Deployment cũng chỉ định một chiến lược (strategy) để khởi động lại Pod khi chúng die hoặc crash

ReplicaSet được tạo khi Deployment được tạo hoặc được chỉnh sửa ReplicaSet được dùng như định nghĩa để tạo Pod Sơ đồ sau mô tả mối quan hệ giữa Deployment, ReplicaSet và Pod trong Kubernetes [14]

26

Hình 2.11: Mối quan hệ giữa Deployment, ReplicaSet và Pod trong Kubernetes

2.3.5 Label và Selector trong Kubernetes

Label (nhãn) là một trong những khái niệm Kubernetes cơ bản Label là một cặp value gắn vào một tài nguyên Kubernetes Và mỗi tài nguyên Kubernetes có thể có một hoặc nhiều label Label phục vụ như một phương tiện để xác định cụ thể một Resource hoặc tập hợp các Resource

key-Label Selector cũng là các cặp key-value Chúng dùng để chọn một label nhất định hoặc một tập hợp các label Theo cơ chế này, một loại Resource có thể chọn (select) một hoặc nhiều các Resources thuộc loại khác Label còn được dùng với kubectl để truy vấn các loại Resource nhất định

Sơ đồ sau mô tả cơ chế lựa chọn này với Service chọn một nhóm Pod qua selector [14]

Hình 2.12: Cơ chế lựa chọn Label Selector

2.3.6 NameSpace

Trong Kubernetes, NameSpace là nơi chúng ta đặt tất cả lại với nhau Một NameSpace

có thể được coi là giống như một môi trường Tập hợp các tài nguyên có thể được triển khai vào NameSpace để tạo thành một nhóm các thành phần liên quan

27

Hình 2.13: NameSpace trong Kubernrtes

Ví dụ về việc sử dụng NameSpace có thể là để tạo môi trường DEV hoặc chia sẻ một tập hợp các dịch vụ được sử dụng bởi các NameSpaces khác

CHƯƠNG 3 GIẢI PHÁP AUTOSCALING

Chương này sẽ trình bày chi tiết về Autoscaling, các phương pháp Autoscaling, thuật toán, cách hoạt động và sử dụng Qua đó áp dụng các phương pháp trong chương sau

3.1 Horizontal Autoscaling

Tự mở rộng chiều dọc(Horizontal Autoscaling) là cách mở rộng mà ta sẽ tăng số lượng worker (application) đang xử lý công việc hiện tại ra nhiều hơn Ví dụ ta đang có 2 Pod

để xử lý cho client, khi số lượng client tăng đột biến, 2 Pod hiện tại không thể xử lý kịp,

ta sẽ mở rộng số lượng Pod lên thành 4 Pod để có thể đáp ứng được số lượng client [15]

Hình 3.1: Mô hình Horizontal Pod Autoscaler

28

3.1.1 Quá trình Autoscaling

Quá trình autoscaling được chia thành 3 giai đoạn:

• Thu thập metrics của tất cả các Pod được quản lý bởi scalable resource mà ta chỉ định trong HPA

• Tính toán số lượng Pod cần thiết dựa vào metrics thu thập được

• Cập nhật lại trường replicas của scalable resource [15]

29

Hình 3.2: Quy trình thu thập Metrics

3.1.3 Tính toán số lượng Pod cần thiết

Sau khi horizontal controller thu thập được metric, nó sẽ tiến hành giai đoạn tiếp theo là tính toán số lượng Pod dựa theo metric thu thập được với số metric được chỉ định trong HPA, nó sẽ tính ra số replicas từ metric theo một công thức có sẵn Với giá trị đầu vào

là một nhóm pod metrics và đầu ra là số replicas tương ứng Công thức dạng đơn giản như sau: [15]

30

Bảng 3.1: Công thức tính số replicas đơn giản

desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]

3.1.3.1 Cấu hình chỉ có một metric

Khi một HPA cấu hình chỉ có một metric (chỉ có cpu hoặc memory) thì việc tính toán

số lượng Pod chỉ có một bước là sử dụng công thức trên Ví dụ với chỉ số CPU, ta có giá trị current metric hiện tại là 200m, giá trị desired là 100m, current replicas là 2, ta sẽ có:

3.1.3.2 Cấu hình nhiều metric

Khi HPA của ta cấu hình mà có nhiều metric, ví dụ có cả cpu và Queries-Per-Second (QPS), thì việc tính toán cũng không phức tạp hơn lắm, horizontal controller sẽ tính ra giá trị replicas của từng metric riêng lẻ, sau đó sẽ lấy giá trị replicas lớn nhất

Bảng 3.2: Công thức lựa chọn số replicas với nhiều metric

max([metric_one, metric_two, n])

Ví dụ, ta có số replicas sau khi tính ra của cpu là 4, của Queries-Per-Second là 3, thì max(4, 3) = 4, số lượng replicas sẽ được scale lên là 4 [15]

• Deployments: quản lý một nhóm các Pod - tự động thay thế các Pod bị lỗi, không phản hồi bằng pod mới, đảm bảo số pod cho hoạt động của ứng dụng

• ReplicationControllers: đảm bảo hoạt động cho một nhóm các Pod theo label

• ReplicaSets: đảm bảo hoạt động cho nhóm các Pod theo label tương tự ReplicationControllers nhưng có thể sử dụng với các nhóm pod có label khác nhau

• StatefulSets: đảm bảo hoạt động cho nhóm các Pod theo label tương tự ReplicaSets nhưng chặt chẽ hơn trong quản lý pod, sử dụng với các ứng dụng stateful, service dạng database như mariadb, mysql [15]