[Note] Khóa học Kubernetes cơ bản (tiếng Việt) – Phần 1 – Chap 1 – 4

Khóa học này sẽ bao gồm 15 module, cung cấp cho người học các kiến thức về kiến trúc của K8s, cách cài đặt và sử dụng, cách xây dựng các thành phần của một ứng dụng container, quản lý Volume, phân quyền và truy cập, secrets.

Các chương sẽ được upload dần dần.

Syllabus:

Chapter 1. From Monolith to Microservices

Chapter 2. Container Orchestration

Chapter 3. Kubernetes

Chapter 4. Kubernetes Architecture

Chapter 5. Installing Kubernetes

Chapter 6. Minikube – Installing Local Kubernetes Clusters

Chapter 7. Accessing Minikube

Chapter 8. Kubernetes Building Blocks

Chapter 9. Authentication, Authorization, Admission Control

Chapter 10. Services

Chapter 11. Deploying a Stand-Alone Application

Chapter 12. Kubernetes Volume Management

Chapter 13. ConfigMaps and Secrets

Chapter 14. Ingress

Chapter 15. Advanced Topics

Các bài học sẽ sử dụng Minikube để demo, mình đã test thì đa số PC hoàn toàn đáp ứng với việc chạy Minikube. Tuy nhiên, mình sẽ cố gắng customize, add thêm notes về việc sử dụng Kind – để máy yếu hơn cũng có thể chạy được các cụm K8s cho mục đích phát triển, học tập.

Hướng dẫn

Đây là phần đầu tiên của khoá học, bạn có thể xem tiếp các phần tại:

Phần 2: https://shinchan.asia/2023/12/20/khoa-hoc-kubernetes-co-ban-tieng-viet-phan-2-chap-5-8/

Phần 3: https://shinchan.asia/2024/04/13/note-khoa-hoc-kubernetes-co-ban-notes-tieng-viet-phan-3-chap-9-12/

Phần 4: https://shinchan.asia/2024/04/13/note-khoa-hoc-kubernetes-co-ban-tieng-viet-phan-4-chap-13-15/

Bonus:

Cách dựng 1 cluster Kubernetes phục vụ mục đích phát triển trong 2 phút:

https://shinchan.asia/2023/09/16/cach-dung-1-cluster-kubernetes-phuc-vu-muc-dich-phat-trien-trong-2-phut

Giải quyết lỗi Kubernetes Load Balancer External IP luôn ở trạng thái Pending:

https://shinchan.asia/2023/09/16/giai-quyet-loi-kubernetes-load-balancer-external-ip-luon-o-trang-thai-pending

Chạy VM trên VirtualBox bằng Vagrant

https://shinchan.asia/2023/03/19/chay-vm-tren-virtualbox-bang-vagrant

Chapter 1. From Monolith to Microservices

Các ứng dụng Monolith cổ đại/cổ điển

Mặc dù hầu hết các doanh nghiệp tin rằng đám mây sẽ là ngôi nhà mới cho các ứng dụng truyền thống, nhưng không phải tất cả các chương trình truyền thống đều phù hợp với đám mây.

Một con tàu nặng 1000 tấn không dễ dàng để mang theo. Tảng đá này này đại diện cho các ứng dụng monolith – các lớp tính năng và redundant logic được dịch thành hàng ngàn dòng mã, được viết bằng một ngôn ngữ lập trình duy nhất, không quá hiện đại, dựa trên các mô hình và nguyên tắc kiến trúc phần mềm lỗi thời.

Theo thời gian, các tính năng mới và cải tiến được thêm vào sự phức tạp của mã, làm cho việc phát triển trở nên khó khăn hơn – thời gian tải, biên dịch và xây dựng tăng lên với mỗi bản cập nhật mới. Tuy nhiên, có nó lại dễ dàng trong quản trị vì ứng dụng chạy trên một máy chủ duy nhất, lý tưởng là một máy ảo hoặc Mainframe.

Một monolith có có phần cứng khá đắt tiền. Là một phần mềm lớn, đơn lẻ đang phát triển liên tục, nó phải chạy trên một hệ thống duy nhất phải đáp ứng các yêu cầu về tính toán, bộ nhớ, lưu trữ và network. Phần cứng có công suất như vậy không chỉ phức tạp và cực kỳ tốn kém, mà đôi khi cũng rất khó để mua.

Bởi vì toàn bộ ứng dụng monolith chạy như một quy trình duy nhất, việc mở rộng các đặc điểm riêng lẻ của monolith là gần như không thể. Nó hỗ trợ nội bộ một số lượng nhất định kết nối và hoạt động (hardcoded). Tuy nhiên, việc mở rộng toàn bộ ứng dụng có thể được thực hiện bằng cách triển khai một phiên bản mới của monolith trên một máy chủ khác, thường đằng sau một thiết bị cân bằng tải – một giải pháp đắt tiền khác.

Trong quá trình nâng cấp, bản vá hoặc di chuyển của ứng dụng monolith, downtime là không thể tránh khỏi và maintenance windows phải được lên kế hoạch tốt trước vì sự gián đoạn trong dịch vụ dự kiến sẽ ảnh hưởng đến khách hàng. Trong khi có các giải pháp của bên thứ ba để giảm thiểu downtime cho khách hàng bằng cách thiết lập các ứng dụng monolith trong cấu hình highly available active/passive, chúng làm phát sinh những thách thức mới cho các kỹ sư hệ thống để giữ cho tất cả các hệ thống ở cùng một patch level và có thể phát sinh các licensing costs mới.

Kiến trúc Microservices (dịch vụ vi mô) hiện đại

Microservices có thể được ví như những viên sỏi, không giống như những viên đá 1000 tấn, dễ xử lý hơn nhiều. Chúng được chạm khắc ra từ monolith, tách biệt với nhau, trở thành các thành phần phân tán từng được mô tả bởi một tập hợp các đặc điểm cụ thể. Một khi cân tất cả cùng nhau, những viên đá tạo nên trọng lượng của toàn bộ đống đá. Những viên đá này đại diện cho các dịch vụ nhỏ được kết nối rời rạc, mỗi dịch vụ thực hiện một chức năng kinh doanh cụ thể. Tất cả các chức năng được nhóm lại với nhau tạo thành chức năng tổng thể của ứng dụng đơn thuần ban đầu.

Các microservices có thể được triển khai riêng lẻ trên các máy chủ riêng biệt được cung cấp với ít tài nguyên hơn – chỉ những gì được yêu cầu bởi mỗi dịch vụ và chính hệ thống máy chủ, giúp giảm chi phí tài nguyên tính toán.

Kiến trúc dựa trên microservices phù hợp với các nguyên tắc của kiến trúc hướng sự kiện và kiến trúc định hướng dịch vụ (SOA), trong đó các ứng dụng phức tạp bao gồm các quy trình độc lập nhỏ giao tiếp với nhau thông qua giao diện lập trình ứng dụng (API) trên mạng. API cho phép truy cập bởi các dịch vụ nội bộ khác của cùng một ứng dụng hoặc bên ngoài, dịch vụ và ứng dụng của bên thứ ba.

Mỗi microservices được phát triển và viết bằng một ngôn ngữ lập trình hiện đại, được lựa chọn để phù hợp nhất với loại dịch vụ và chức năng kinh doanh của nó. Điều này cung cấp rất nhiều tính linh hoạt khi kết hợp các microservice với phần cứng cụ thể khi cần thiết, cho phép triển khai trên phần cứng hàng hoá rẻ tiền.

Mặc dù bản chất phân tán của các microservice làm cho kiến trúc trở nên phức tạp hơn, nhưng một trong những lợi ích lớn nhất của microservice là khả năng mở rộng. Với việc ứng dụng tổng thể trở nên mô-đun, mỗi microservice có thể được mở rộng riêng lẻ, bằng tay hoặc tự động thông qua quy mô tự động dựa trên nhu cầu.

Nâng cấp liền mạch và quá trình sửa lỗi là những lợi ích khác của kiến trúc dịch vụ vi mô. Không có thời gian ngừng hoạt động và không có sự gián đoạn dịch vụ cho khách hàng vì các bản nâng cấp được triển khai một cách liền mạch – một dịch vụ mỗi lần, thay vì phải biên dịch lại, xây dựng lại và khởi động lại toàn bộ một ứng dụng đơn điệu. Kết quả là, các doanh nghiệp có thể phát triển và triển khai các tính năng mới và cập nhật nhanh hơn nhiều, theo một cách tiếp cận nhanh nhẹn, có các nhóm riêng biệt tập trung vào những tính năng riêng biệt, do đó hiệu quả hơn và hiệu quả về chi phí.

Refactoring (tái tạo/tái cấu trúc)

Các doanh nghiệp mới hơn, hiện đại hơn sở hữu kiến thức và công nghệ để xây dựng các ứng dụng dựa trên đám mây để thúc đẩy hoạt động kinh doanh của họ.

Thật không may, các công ty đã thành lập sử dụng các ứng dụng monolithic không phù hợp. Một số người đã cố gắng sử dụng monoliths như dịch vụ vi mô (microservices), nhưng họ không thành công. Một ứng dụng đa quy trình có kích thước đơn lẻ không thể hoạt động như một dịch vụ vi mô, vì vậy cần phải xem xét các phương pháp khác.

Refactoring (tái tạo): Bước tiếp theo trong quá trình chuyển đổi từ dịch vụ đơn độc sang dịch vụ vi mô. Tuy nhiên, việc thực hiện refactoring để chuyển một ứng dụng hàng thập kỷ tuổi sang điện toán đám mây gây ra những vấn đề nghiêm trọng và doanh nghiệp phải đối mặt với việc lựa chọn cách tiếp cận refactoring: “Big-bang” hay tái tạo gia tăng (incremental refactoring).

Một cách tiếp cận được gọi là “Big-bang” tập trung tất cả nỗ lực vào việc refactoring monolith, trì hoãn sự phát triển và thực hiện bất kỳ tính năng mới nào. Điều này về cơ bản trì hoãn tiến trình và có thể phá vỡ cốt lõi của monolith business.

Tái tạo gia tăng là một phương pháp khác để đảm bảo rằng các tính năng mới được phát triển và thực hiện, chẳng hạn như các dịch vụ vi mô hiện đại, có thể giao tiếp với monolith thông qua các API mà không cần phải thêm code vào monolith. Khi các tính năng được tái tạo, tất cả hoặc phần lớn các chức năng của nó đã được chuyển thành các dịch vụ vi mô. Cách tiếp cận gia tăng này cho phép chuyển đổi dần dần từ một đơn vị cổ xưa sang kiến trúc vi dịch vụ hiện đại và cho phép các tính năng ứng dụng di chuyển từng bước vào đám mây.

Một công ty sẽ phải đưa ra nhiều quyết định khác nhau khi quyết định tái tạo. Chúng bao gồm việc xác định những business component nào được tách ra từ đơn vị để trở thành microservices phân tán, cách tách các cơ sở dữ liệu khỏi ứng dụng để tách sự phức tạp dữ liệu ra khỏi logic ứng dụng, cách kiểm tra các dịch vụ vi mới và sự phụ thuộc của chúng,…

Bằng cách sử dụng các ngôn ngữ lập trình mới và các mô hình kiến trúc hiện đại, giai đoạn tái tạo dần dần biến monolith thành một ứng dụng cloud native tận dụng toàn bộ các tính năng của đám mây. Một ứng dụng monolith cổ đại nhận được một cơ hội thứ hai trong cuộc sống thông qua việc tái tạo. Điều này cho phép nó sống sót như một hệ thống modular và thích nghi để tích hợp các công cụ và dịch vụ tự động hóa đám mây hiện đại.

Các thách thức

Tiến trình tái tạo từ dịch vụ đơn độc sang dịch vụ vi mô không hề dễ dàng. Một số monolith không phù hợp với việc tái tạo, trong khi một số thậm chí có thể không “sống sót” trong quá trình hiện đại hóa. Khi quyết định liệu một monolith có phải là một ứng cử viên tiềm năng để tái tạo hay không, có nhiều vấn đề cần được xem xét.

Nó có thể còn tiết kiệm hơn để cần xây dựng lại nó từ đầu như một ứng dụng cloud native nếu hệ thống hiện tại là một hệ thống cổ đại dựa trên mainframe được viết bằng các ngôn ngữ lập trình cũ hơn, chẳng hạn như Cobol hoặc Assembler. Các ứng dụng cũ có thiết kế kém nên được thiết kế lại từ đầu sử dụng các mô hình kiến trúc hiện đại cho các dịch vụ vi mô và thậm chí cả container. Các ứng dụng cũng không phù hợp với việc tái tạo khi chúng được kết hợp chặt chẽ với kho dữ liệu.

Một khi monolith đã vượt qua giai đoạn tái tạo, thách thức tiếp theo là tạo ra một phương pháp hoặc tìm ra các công cụ phù hợp để đảm bảo rằng toàn bộ ứng dụng có thể được phục hồi.

Chọn thời gian chạy cũng có thể là một vấn đề. Các thư viện và môi trường chạy thời gian khác nhau có thể xung đột với nhau, gây ra lỗi và thất bại, nếu nhiều mô-đun được thực hiện trên cùng một máy chủ vật lý hoặc ảo. Điều này đòi hỏi phải thiết lập các mô-đun riêng lẻ cho mỗi máy chủ để tránh phụ thuộc vào nhau – đây không phải là một cách quản lý tài nguyên tiết kiệm và hiệu quả, và không có sự tách biệt thực sự của các thư viện và thời gian chạy, vì mỗi máy ảo cũng có một hệ điều hành cơ bản chạy với các libraries của nó, do đó tiêu thụ tài nguyên máy chủ – đôi khi các process Operating System của máy ảo còn tiêu tốn nhiều tài nguyên server hơn bản thân ứng dụng.

Cuối cùng, những vấn đề này đã được giải quyết. Các ứng dụng containerized đi kèm với việc cung cấp lightweight runtime environments được đóng gói cho các mô-đun ứng dụng. Các container hứa hẹn các môi trường phần mềm nhất quán cho các developers, testers, từ phát triển đến sản xuất. Khả năng chuyển đổi các ứng dụng từ vật lý bare-metal đến máy ảo được đảm bảo bởi nhờ có công nghệ container. Nhiều ứng dụng được triển khai trên cùng một máy chủ, mỗi ứng dụng chạy trong môi trường thực hiện riêng của họ tách biệt với nhau, do đó tránh xung đột, lỗi và thất bại. Khả năng sử dụng máy chủ cao hơn, khả năng mở rộng mô-đun riêng lẻ, tính linh hoạt, tương tác và dễ dàng tích hợp với các công cụ tự động hóa là những tính năng khác của môi trường ứng dụng container.

Câu chuyện thành công

Mặc dù đó là một quá trình khó khăn, nhưng việc chuyển từ monoliths sang microservices là một quá trình có lợi. Điều này đặc biệt đúng khi một công ty bắt đầu nhận được lợi ích từ việc tái tạo hệ thống ứng dụng của mình. Dưới đây là một số ví dụ về các công ty đã thành công khi giải quyết vấn đề hiện đại hóa các ứng dụng kinh doanh monolith của họ. Trang web Kubernetes chứa một danh sách các case studies thành công:

https://kubernetes.io/case-studies/

– AppDirect – một end-to-end commerce platform provider, bắt đầu từ một ứng dụng monolith phức tạp và thông qua việc tái tạo đã có thể duy trì các monolith chức năng hạn chế nhận được rất ít cam kết, nhưng tất cả các tính năng mới phát triển theo hướng containerized microservices.
– box – một nhà cung cấp giải pháp lưu trữ đám mây, bắt đầu từ một kiến trúc monolith phức tạp và thông qua tái tạo đã có thể phân tách nó thành các dịch vụ vi mô.

Chapter 2. Container Orchestration

Container images cho phép chúng ta giới hạn code ứng dụng, runtimes của nó, và tất cả các dependencies của nó trong một định dạng được xác định trước. Các container runtime như runC, containerd, hoặc cri-o có thể sử dụng pre-packaged images làm source để tạo và chạy một hoặc nhiều container. Những runtimes này có khả năng chạy các container trên một máy chủ duy nhất, tuy nhiên, trong thực tế, chúng tôi muốn có một giải fault-tolerant và có scalable, điều này có thể đạt được bằng cách xây dựng một controller/management unit, – một collection nhiều hosts kết nối với nhau. Controller/management unit này thường được gọi là container orchestrator.

Trong chương này, chúng ta sẽ khám phá lý do tại sao chúng ta nên sử dụng các container orchestrators, các implementations khác nhau của các container orchestrators, và nơi triển khai chúng.

Đến cuối chương này, bạn nên có thể:

Xác định khái niệm container orchestration.
Giải thích những lợi ích của việc sử dụng container orchestration.
Thảo luận các tùy chọn container orchestration khác nhau.
Thảo luận các tùy chọn triển khai container orchestration khác nhau.

Container là gì?

Trước khi chúng ta đi sâu vào việc container orchestration, trước tiên chúng ta hãy xem xét container là gì.

Containers là một application-centric method để cung cấp các ứng dụng hiệu suất cao, có thể mở rộng trên bất kỳ cơ sở hạ tầng nào bạn chọn. Các container phù hợp nhất để cung cấp dịch vụ vi mô bằng cách cung cấp các môi trường ảo di động, cô lập cho các ứng dụng chạy mà không bị nhiễu bởi những ứng dụng đang chạy khác.

Microservices là các ứng dụng nhẹ được viết bằng các ngôn ngữ lập trình hiện đại khác nhau, với dependencies, libraries và yêu cầu môi trường cụ thể. Để đảm bảo rằng một ứng dụng có mọi thứ cần thiết để chạy thành công, nó được đóng gói cùng với các dependencies của nó.

Các container encapsulate và các dependencies của chúng nhưng không chạy chúng trực tiếp. Các container chạy container images.

Một container image gói ứng dụng cùng với runtime, libraries và dependencies của nó, và nó đại diện cho nguồn của một container được triển khai để cung cấp một môi trường chạy riêng biệt cho ứng dụng. Container có thể được triển khai từ một image cụ thể trên nhiều nền tảng, chẳng hạn như workstations, Virtual Machines, public cloud, v.v.

Container orchestration là gì?

Trong môi trường phát triển (Dev), chạy container trên một máy chủ duy nhất để phát triển và thử nghiệm các ứng dụng có thể là một lựa chọn thích hợp. Tuy nhiên, khi chuyển sang môi trường đảm bảo chất lượng (QA) và sản xuất (Prod), đó không còn là một lựa chọn khả thi vì các ứng dụng và dịch vụ cần đáp ứng các yêu cầu cụ thể:

– Fault-tolerance
– Khả năng mở rộng theo yêu cầu
– Sử dụng tài nguyên tối ưu
– Auto-discovery và giao tiếp với nhau một cách tự động
– Nhanh updates/rollbacks mà không có downtime.

Container orchestrators là những công cụ nhóm các hệ thống lại với nhau để hình thành các clusters nơi mà việc triển khai và quản lý container được tự động hoá ở quy mô lớn trong khi đáp ứng các yêu cầu đã đề cập ở trên.

Container orchestrators

Với các doanh nghiệp dịch chuyển ứng dụng lên đám mây, nhu cầu về các giải pháp container orchestration ngày càng tăng. Trong khi có nhiều giải pháp có sẵn, một số chỉ đơn giản là tái phân phối các công cụcontainer orchestration đã được thiết lập, được bổ sung thêm tính năng và, đôi khi, với một số hạn chế về tính linh hoạt.

Mặc dù không đầy đủ, danh sách dưới đây cung cấp một vài công cụ và dịch vụ orchestration container hiện tại có sẵn:-

– Amazon Elastic Container Service (ECS) là một dịch vụ được cung cấp bởi Amazon Web Services (AWS) để chạy các container at scale trên cơ sở hạ tầng của nó.

– Azure Container Instance (ACI) là một dịch vụ container orchestration cơ bản được cung cấp bởi Microsoft Azure.

– Azure Service Fabric là một container orchestrator mã nguồn mở được cung cấp bởi Microsoft Azure.

– Kubernetes là một công cụ container orchestrator mã nguồn mở, ban đầu được phát triển bởi bởi Google, ngày nay là một phần của (CNCF) project:
https://www.cncf.io/

– Marathon là một framework để chạy container trên Apache Mesos và DC/OS.

– Nomad là container and workload orchestrator được cung cấp bởi HashiCorp.

– Docker Swarm là container orchestrator được cung cấp bởi Docker, Inc. Nó là một phần của Công cụ Docker.

Tại sao lại dùng Container Orchestrators?

Mặc dù chúng ta có thể duy trì một vài container theo cách thủ công hoặc viết các kịch bản để quản lý vòng đời của hàng chục container, nhưng orchestrators làm mọi thứ dễ dàng hơn nhiều cho người dùng, đặc biệt là khi quản lý hàng trăm và hàng ngàn container chạy trên global infrastructure.

Hầu hết container orchestrators có thể:

– Nhóm hosts lại cùng nhau tạo một cluster.
– Lập lịch các container để chạy trên hosts trong cluster dựa trên sự sẵn có của tài nguyên.
– Cho phép các container trong một cluster giao tiếp với nhau bất kể máy chủ mà chúng được triển khai trong cluster. (Dù host khác nhau, vẫn có thể connect với nhau)
– Bind containers và storage resources.
– Nhóm các container tương tự và gắn chúng vào các cấu trúc load-balancing để đơn giản hóa truy cập vào các ứng dụng containerized bằng cách tạo ra một interface, một mức độ trừu tượng giữa các container và client.
– Quản lý và tối ưu hóa việc sử dụng tài nguyên.
– Cho phép thực hiện các policies để đảm bảo quyền truy cập vào các ứng dụng chạy bên trong container.

Với tất cả các tính năng linh hoạt này, các container orchestrators rõ ràng là một lựa chọn tuyệt vời khi nói đến việc quản lý các ứng dụng container ở quy mô lớn. Trong khóa học này, chúng ta sẽ khám phá Kubernetes, một trong những công cụ container orchestrators được sử dụng nhiều nhất hiện nay.

Where to deploy container orchestrators?

Hầu hết container orchestrators có thể được triển khai trên cơ sở hạ tầng tùy chọn của chúng ta – trên bare metal, Virtual Machines, on-premises, trên public và hybrid clouds. Ví dụ như Kubernetes, có thể được triển khai trên một workstation, bên trong trung tâm dữ liệu của một công ty, trong đám mây trên các AWS Elastic Compute Cloud (EC2) instance, Google Compute Engine (GCE) VMs, DigitalOcean Droplets, OpenStack, v.v.

Có những giải pháp turnkey cho phép các Kubernetes clusters được cài đặt, chỉ với một vài lệnh, on top Cloud Infrastructures-as-a-Service, chẳng hạn như GCE, AWS EC2, IBM Cloud, Rancher, VMware Tanzu, và các giải pháp multi-cloud thông qua IBM Cloud Private hoặc StackPointCloud.

Cuối cùng nhưng không kém phần quan trọng là managed container orchestration, cụ thể hơn là giải pháp quản lý Kubernetes as-a-Service, được cung cấp và lưu trữ bởi các nhà cung cấp điện toán đám mây lớn, chẳng hạn như Amazon Elastic Kubernetes Service (Amazon EKS), Azure Kubernetes Service (AKS), DigitalOcean Kubernetes, Google Kubernetes Engine (GKE), IBM Cloud Kubernetes Service, Oracle Container Engine for Kubernetes, hay VMware Tanzu Kubernetes Grid.

Chapter 3. Kubernetes

Kubernetes là gì?

“Kubernetes là một hệ thống mã nguồn mở để tự động hoá việc triển khai, mở rộng và quản lý các ứng dụng container”.

Kubernetes có nguồn gốc từ tiếng Hy Lạp κυβερvήτης, có nghĩa là người điều khiển hoặc phi công tàu. Với sự tương đồng này trong tâm trí, chúng ta có thể nghĩ về Kubernetes như là phi công trên một con tàu container.

Kubernetes còn được gọi là k8s (tạm dịch là Kate’s), vì có 8 ký tự giữa k và s.

Kubernetes rất lấy cảm hứng từ hệ thống Google Borg, một nhà tổ chức container và khối lượng công việc cho các hoạt động toàn cầu của nó trong hơn một thập kỷ. Nó là một dự án mã nguồn mở được viết bằng ngôn ngữ Go và được cấp phép theo Giấy phép Apache, Phiên bản 2.0.

Kubernetes được bắt đầu bởi Google và, với bản phát hành v1.0 vào tháng 7 năm 2015, Google đã quyên góp nó cho Cloud Native Computing Foundation (CNCF), một trong những tổ chức con lớn nhất của Linux Foundation.

Phiên bản mới của Kubernetes được phát hành trong chu kỳ 4 tháng. Phiên bản ổn định hiện tại là 1.26 (as of December 2022).

Từ Borg tới Kubernetes

Theo bản tóm tắt của bài báo Borg của Google, được xuất bản vào năm 2015,

“Hệ thống Borg của Google là một hệ thống quản lý đám đông chạy hàng trăm ngàn công việc, từ hàng ngàn ứng dụng khác nhau, trên một số đám đông với hàng chục ngàn máy”.

Trong hơn một thập kỷ, Borg đã là bí mật của Google, điều hành khối lượng công việc chứa trên toàn thế giới trong sản xuất. Các dịch vụ mà chúng ta sử dụng từ Google, chẳng hạn như Gmail, Drive, Maps, Docs, v.v., đều được phục vụ bằng Borg.

Trong số những tác giả ban đầu của Kubernetes là những nhân viên của Google đã sử dụng Borg và phát triển nó trong quá khứ. Họ đổ vào kiến thức và kinh nghiệm có giá trị của họ trong khi thiết kế Kubernetes. Một số đặc điểm/vật thể của Kubernetes có thể được theo dõi trở lại Borg, hoặc những bài học được rút ra từ nó, là:

• API servers

• Pods

• IP-per-Pod

• Services

• Labels.

Kubernetes Features

Kubernetes cung cấp một bộ tính năng rất phong phú cho việc tổ chức container. Một số tính năng được hỗ trợ đầy đủ là:

• Automatic bin packing: Kubernetes tự động lên lịch các container dựa trên nhu cầu tài nguyên và hạn chế, để tối đa hóa việc sử dụng mà không làm mất khả năng sẵn có.

• Designed for extensibility: Một cụm Kubernetes có thể được mở rộng với các tính năng tùy chỉnh mới mà không cần sửa đổi mã nguồn.

• Self-healing: Kubernetes tự động thay thế và sắp xếp lại các container từ các node bị hỏng. Nó terminate và sau đó khởi động lại các container không đáp ứng với healthcheck, dựa trên các quy tắc / chính sách hiện có. Nó cũng ngăn chặn traffic được định tuyến đến các container không đáp ứng.

• Horizontal scaling: Với Kubernetes, các ứng dụng được mở rộng theo cách thủ công hoặc tự động dựa trên việc sử dụng CPU hoặc số liệu tùy chỉnh.

• Service discovery and load balancing: Các container nhận được địa chỉ IP từ Kubernetes, trong khi nó gán một Domain Name System (DNS) duy nhất cho một tập hợp các container để hỗ trợ trong các yêu cầu cân bằng tải trên các tập hợp container.

Các tính năng Kubernetes bổ sung được hỗ trợ đầy đủ là:

• Automated rollouts and rollbacks: Kubernetes rollouts và rolls back các bản cập nhật ứng dụng và các thay đổi cấu hình một cách liền mạch, liên tục theo dõi tình trạng của ứng dụng để ngăn ngừa bất kỳ thời gian ngừng hoạt động nào.

• Secret and configuration management: Kubernetes quản lý dữ liệu nhạy cảm và chi tiết cấu hình cho một ứng dụng riêng biệt với container image, để tránh việc xây dựng lại image tương ứng. Secrets bao gồm thông tin sensitive/confidential được truyền tới ứng dụng mà không tiết lộ nội dung nhạy cảm cho cấu hình stack.

• Storage orchestration: Kubernetes tự động gắn các giải pháp lưu trữ được định nghĩa bởi phần mềm (SDS) vào các container từ các bộ nhớ cục bộ, nhà cung cấp đám mây bên ngoài, bộ nhớ phân tán, hoặc các hệ thống bộ nhớ mạng.

• Batch execution: Kubernetes hỗ trợ thực hiện batch execution, long-running jobs, và thay thế các container thất bại.

• IPv4/IPv6 dual-stack: Kubernetes hỗ trợ cả địa chỉ IPv4 và IPv6.

Có rất nhiều tính năng bổ sung hiện đang ở giai đoạn alpha hoặc beta. Chúng sẽ mang lại giá trị lớn cho bất kỳ việc triển khai Kubernetes nào một khi chúng trở thành các tính năng ổn định. Ví dụ, sự hỗ trợ cho kiểm soát truy cập dựa trên vai trò (RBAC) ổn định ở version 1.8.

Tại sao dùng Kubernetes

Một trong những điểm mạnh của Kubernetes là tính di động (portability). Nó có thể được triển khai trong nhiều môi trường như máy ảo cục bộ hoặc từ xa, bare metal, hoặc trong thiết lập public/private/hybrid/multi-cloud.

Khả năng mở rộng của Kubernetes cho phép nó hỗ trợ và được hỗ trợ bởi nhiều công cụ mã nguồn mở của bên thứ 3 giúp nâng cao khả năng của kubernetes và cung cấp trải nghiệm phong phú cho người dùng. Kiến trúc của nó là modular và có pluggable. Nó không chỉ orchestrate các ứng dụng mô-đun, decoupled microservices, mà kiến trúc của nó cũng theo decoupled microservices patterns. Chức năng của Kubernetes có thể được mở rộng bằng cách viết các custom resources, operators, custom APIs, scheduling rules hoặc plugins.

Đối với một dự án mã nguồn mở thành công, cộng đồng cũng quan trọng. Kubernetes được hỗ trợ bởi một cộng đồng lớn trên toàn thế giới. Nó có hơn 3.200 contributors, những người, theo thời gian, đã push hơn 111.000 commits. Có những meet-up groups ở các thành phố và quốc gia khác nhau thường xuyên gặp nhau để thảo luận về Kubernetes và hệ sinh thái của nó. Cộng đồng được chia thành cácSpecial Interest Groups (SIGs), các nhóm tập trung vào các chủ đề đặc biệt, chẳng hạn như scaling, bare metal, networking, storage, v.v.

Kubernetes Users

Trong chưa đầy một thập kỷ kể từ khi ra mắt, Kubernetes đã trở thành nền tảng lựa chọn cho nhiều doanh nghiệp có kích cỡ khác nhau để chạy workloads của họ. Nó là một giải pháp cho việc quản lý workloads trong ngân hàng, giáo dục, tài chính và đầu tư, gaming, công nghệ thông tin, truyền thông và streaming, bán lẻ online, chia sẻ xe, viễn thông, nghiên cứu hạt nhân, và nhiều ngành công nghiệp khác. Có rất nhiều nghiên cứu trường hợp người dùng và câu chuyện thành công trên trang web Kubernetes:

• BlaBlaCar

• BlackRock

• Booking.com

• Box

• CapitalOne

• Haufe Group

• Huawei

• IBM

• ING

• Nokia

• Pearson

• Wikimedia

Và nhiều hơn nữa.

Cloud Native Computing Foundation (CNCF)

Cloud Native Computing Foundation (CNCF) là một trong những dự án phụ lớn nhất được tổ chức bởi Linux Foundation. CNCF nhằm đẩy nhanh việc áp dụng các container, dịch vụ vi mô và các cloud-native applications.

CNCF hosts một loạt các dự án, với nhiều dự án khác sẽ được thêm vào trong tương lai. CNCF cung cấp nguồn lực cho từng dự án, nhưng đồng thời, mỗi dự án tiếp tục hoạt động độc lập dưới cấu trúc quản trị hiện có và với những maintainers hiện có. Các dự án trong CNCF được phân loại dựa trên mức độ trưởng thành: Sandbox, Incubating, và Graduated. Vào thời điểm viết bài này, rất nhiều dự án đã đạt được trạng thái Graduated với nhiều dự án khác Incubating và Sandbox.

Các dự án Graduated phổ biến:

• Kubernetes container orchestrator

• etcd distributed key-value store

• CoreDNS DNS server

• containerd container runtime

• Envoy cloud native proxy

• Fluentd for unified logging

• Harbor registry

• Helm package management for Kubernetes

• Linkerd service mesh for Kubernetes

• Open Policy Agent policy engine

• Prometheus monitoring system and time series DB

• Rook cloud native storage orchestrator for Kubernetes

Key incubating projects:

• argo workflow engine for Kubernetes

• Buildpacks.io builds application images

• CRI-O container runtime

• Contour ingress controller for Kubernetes

• gRPC for remote procedure call (RPC)

• CNI for Linux containers networking

• flux continuous delivery for Kubernetes

• Knative serverless containers in Kubernetes

• KubeVirt Kubernetes based Virtual Machine manager

• Notary for data security

• And many more.

Có rất nhiều dynamic projects trong CNCF Sandbox hướng tới đo lường, giám sát, nhận dạng, scripting, serverless, nodeless, edge, mong muốn đạt được trạng thái Incubating và có thể là Graduated. Trong khi nhiều dự án hoạt động đang chuẩn bị khởi động, những dự án khác đang được archived khi họ trở nên ít hoạt động hơn và không còn nhu cầu nữa. Các dự án đầu tiên được archived là rkt container runtime, distributed OpenTracing, và Brigade, một event driven automation tool.

Các dự án dưới CNCF bao gồm toàn bộ vòng đời của một cloud-native application, từ việc thực hiện nó bằng container runtimes, cho đến monitoring và logging. Điều này rất quan trọng để đạt được mục tiêu của CNCF.

CNCF và Kubernetes

Đối với Kubernetes, Cloud Native Computing Foundation:

• Cung cấp một ngôi nhà trung lập cho Kubernetes trademark và enforces cách sử dụng thích hợp.

• Cung cấp license scanning core và vendor code.

• Cung cấp hướng dẫn pháp lý về các vấn đề về bằng sáng chế và bản quyền.

• Tạo và duy trì chương trình giảng dạy học tập mã nguồn mở, đào tạo và chứng nhận cho Kubernetes

• Hoạt động tiếp thị Kubernetes.

• Hỗ trợ các hoạt động đặc biệt.

• Tài trợ cho các hội nghị và các sự kiện hội nghị.

Chapter 4. Kubernetes Architecture

Chapter Overview

Trong chương này, chúng ta sẽ khám phá kiến trúc Kubernetes, các thành phần của control plane node, vai trò của các worker nodes, cluster state management với etcd và các network setup requirements. Chúng ta cũng sẽ tìm hiểu về Container Network Interface (CNI), và thông số kỹ thuật mạng của Kubernetes.

Learning Objectives

Đến cuối chương này, bạn nên có thể:

• Thảo luận về kiến trúc Kubernetes.

• Giải thích các thành phần khác nhau của bảng điều khiển và các nút làm việc.

• Thảo luận về quản lý trạng thái cluster với etcd.

• Xem xét các yêu cầu thiết lập mạng Kubernetes.

Kubernetes Architecture

Ở mức độ high level, Kubernetes là một tập hợp các hệ thống tính toán được phân loại theo vai trò riêng biệt của chúng:

• Một hoặc nhiều control plane

• Một hoặc nhiều worker (optional, but recommended).

Control Plane Node Overview

Control plane node cung cấp một môi trường chạy cho control plane agents chịu trách nhiệm quản lý trạng thái của một cụm Kubernetes, và nó là bộ não đằng sau tất cả các hoạt động bên trong cluster. Các thành phần của control plane là các agents có vai trò rất riêng biệt trong việc quản lý các cluster. Để giao tiếp với Kubernetes cluster, người dùng gửi yêu cầu đến control plane thông qua Command Line Interface (CLI) tool, một Web User-Interface (Web UI) Dashboard, hoặc một Application Programming Interface (API).

Điều quan trọng là phải giữ cho control plane hoạt động bằng mọi giá. Mất control plane có thể gây ra downtime, gây ra sự gián đoạn dịch vụ cho khách hàng, gây thiệt hại tới việc kinh doanh. Để đảm bảo khả năng fault tolerance của máy điều khiển, control plane node replicas có thể được thêm vào cluster, được cấu hình trong chế độ High-Availability (HA). Trong khi chỉ có một trong các control plane nodes được dành riêng cho actively managing các cluster, các control plane components vẫn đồng bộ giữa các control plane node replicas. Kiểu cấu hình này làm tăng khả năng phục hồi cluster’s control plane của cluster, trong trường hợp active control plane node fail.

Để duy trì trạng thái của Kubernetes cluster, tất cả dữ liệu cấu hình tập hợp được lưu vào distributed key-value store chỉ chứa dữ liệu liên quan đến trạng thái tập hợp, không có dữ liệu workload được tạo ra bởi client. Key-value store may có thể được cấu hình trên control plane node (stacked topology), hoặc trên máy chủ its dedicated host (external topology) để giúp giảm nguy cơ mất dữ liệu bằng cách decoupling nó ra khỏi các control plane agents khác.

Trong stacked key-value store topology, HA control plane node replicas đảm bảo khả năng phục hồi của key-value store. Tuy nhiên, đó không phải đúng với external key-value store topology, nơi mà dedicated key-value store hosts phải được replicated riêng biệt cho HA, một cấu hình introduces sự cần thiết cho phần cứng bổ sung, và dẫn tới chi operational costs bổ sung.

Control Plane Node Components

Một nút điều khiển phẳng chạy control plane components và tác nhân thiết yếu sau đây:

• API Server

• Scheduler

• Controller Managers

• Key-Value Data Store.

Ngoài ra, control plane node chạy:

• Container Runtime

• Node Agent

• Proxy

• Optional add-ons for cluster-level monitoring and logging.

Control Plane Node Components: API Server

Tất cả các administrative tasks được coordinated bởi kube-apiserver, một control plane component trung tâm chạy trên control plane node. API Server nhận các RESTful calls từ users, administrators, developers, operators và các external agents, sau đó xác nhận và xử lý chúng. Trong quá trình xử lý, API Server đọc trạng thái hiện tại của cụm Kubernetes từ key-value store, và mỗi call’s execution, trạng thái của Kubernetes cluster được lưu trong key-value store để persistence. API Server là control plane component duy nhất để nói chuyện với key-value store, cả để đọc từ và lưu thông tin trạng thái cụm Kubernetes – nó hoạt động như một interface trung gian cho bất kỳ control plane agent nào khác inquiring về cluster’s state.

API Server rất có thể cấu hình và tùy chỉnh. Nó có thể mở rộng theo chiều ngang, nhưng nó cũng hỗ trợ việc thêm các máy chủ API thứ cấp tùy chỉnh, một cấu hình biến đổi primary API Server thành một proxy cho tất cả các secondary, custom API Servers, routing tất cả những incoming RESTful calls vào chúng dựa trên các custom defined rules.

Control Plane Node Components: Scheduler

Vai trò của Kube-scheduler là assign các workload objects mới, chẳng hạn như pods encapsulating containers, cho tới các nodes – thường là các worker nodes. Trong scheduling process, các quyết định được đưa ra dựa trên trạng thái hiện tại của Kubernetes cluster và yêu cầu của workload objects mới. Scheduler lấy dữ liệu sử dụng tài nguyên từ key-value store, thông qua API Server, cho mỗi worker node trong cụm. Scheduler cũng nhận được từ API Server các yêu cầu của workload objects – một phần của dữ liệu cấu hình của nó. Yêu cầu có thể bao gồm các hạn chế mà người dùng và người vận hành thiết lập, chẳng hạn như scheduling work trên một node có nhãn là key-value pair disk==ssd. Scheduler cũng tính đến các Quality of Service (QoS) requirements, data locality, affinity, anti-affinity, taints, toleration, cluster topology, v.v. Một khi tất cả dữ liệu cluster đã sẵn sàng, thuật toán lập lịch sẽ lọc các nodes với predicates để cô lập các ứng cử viên node có sẵn, sau đó đánh giá dựa trên priorities để chọn một node đáp ứng tất cả các yêu cầu cho việc lưu trữ khối lượng công việc mới. Kết quả của quá trình quyết định được truyền lại cho máy chủ API, sau đó chuyển giao nhiệm vụ vận hành cho các control plane agents khác.

Scheduler có thể được cấu hình và tùy chỉnh thông qua các scheduling policies, plugins, and profiles. Các custom schedulers cũng được hỗ trợ, object’s configuration data nên bao gồm tên của custom scheduler dự kiến sẽ đưa ra scheduling decision cho đối tượng cụ thể đó; nếu không có dữ liệu như vậy được bao gồm, thì default scheduler sẽ được chọn thay thế.

Một scheduler cực kỳ quan trọng và phức tạp trong một multi-node Kubernetes cluster, trong khi trong single-node Kubernetes clusters – các cluster thể được sử dụng cho mục đích học tập và phát triển – scheduler’s job khá đơn giản.

Control Plane Node Components: Controller Managers

Các controller managers là các thành phần của control plane node chạy các controllers hoặc operator processes để điều chỉnh trạng thái của cụm Kubernetes. Controllers là watch-loop processes liên tục chạy và so sánh trạng thái mong muốn của cluster (được cung cấp bởi dữ liệu cấu hình của đối tượng) với trạng thái hiện tại của nó (obtained from the key-value store via the API Server). Trong trường hợp không phù hợp, hành động sửa chữa được thực hiện trong cụm cho đến khi trạng thái hiện tại của nó khớp với trạng thái mong muốn.

kube-controller-manager chạy các controllers hoặc operators chịu trách nhiệm hành động khi các node trở nên unavailable, để đảm bảo số lượng pod container là như mong đợi, tạo endpoints, service accounts, và API access tokens.

Cloud-controller-manager chạy các controllers hoặc các operators chịu trách nhiệm tương tác với cơ sở hạ tầng cơ bản của cloud provider khi các node trở nên unavailable, quản lý storage volumes khi được cung cấp bởi một cloud service, quản lý cân bằng tải và định tuyến.

Control Plane Node Components: Key-Value Data Store

etcd là một dự án mã nguồn mở dưới nền tảng Cloud Native Computing Foundation (CNCF). etcd là một strongly consistent, distributed key-value data store, được sử dụng để duy trì trạng thái của một cụm Kubernetes. Chỉ có thể thêm dữ liệu mới vào data store; dữ liệu không bao giờ được thay thế. Định kỳ, dữ liệu lỗi thời được nén để giảm kích thước của data store.

Trong tất cả các control plane components, chỉ có API Server có thể giao tiếp với etcd data store.

etcd’s CLI management tool – etcdctl, cung cấp khả năng lưu trữ và khôi phục ảnh snapshot, đặc biệt hữu ích cho một single etcd instance Kubernetes cluster – rất phổ biến trong môi trường phát triển và học tập. Tuy nhiên, trong môi trường Stage và Production, việc replicate data stores ở HA mode là cực kỳ quan trọng, để có thể duy trì cluster configuration data resiliency.

Một số Kubernetes cluster bootstrapping tools, chẳng hạn như kubeadm, mặc định cung cấp stacked etcd control plane nodes, data store chạy cùng nhau và chia sẻ tài nguyên với các control plane components khác trên cùng một control plane node.

Để cách ly data store từ các control plane components, bootstrapping proces có thể được cấu hình cho external etcd topology, nơi mà data store được cung cấp trên một máy chủ riêng biệt. Điều này giúp giảm sự cố etcd.

Cả stacked và external etcd topologies đều hỗ trợ cấu hình HA. etcd dựa trên Raft Consensus Algorithm cho phép một bộ sưu tập các machines hoạt động như một nhóm nhất quán có thể sống sót sau những sự cố của một số members. Tại bất kỳ thời điểm nào, một trong những node trong group sẽ là leader, và phần còn lại của họ sẽ là những followers. Các cuộc bầu leader được thực hiện bởi etcd và nó cũng có thể chịu đựng các sự cố node, bao gồm cả sự cố node leader. Bất kỳ nút nào cũng có thể được coi là leader.

etcd được viết bằng ngôn ngữ lập trình Go. Trong Kubernetes, ngoài việc lưu trữ trạng thái cluster, etcd cũng được sử dụng để lưu các chi tiết cấu hình như subnet, ConfigMaps, Secrets, v.v.

Worker Node Overview

Một worker node việc cung cấp một môi trường chạy cho các client applications. Các ứng dụng này là microservices chạy dưới dạng application containers. Trong Kubernetes, các application containers được encapsulated trong Pods, được điều khiển bởi các cluster control plane agents chạy trên nút điều khiển. Pod được scheduling trên các worker nodes, nơi chúng tìm thấy các tài nguyên cần thiết như compute, memory, storage, và networking giao tiếp với nhau và với thế giới bên ngoài. Một Pod là scheduling work unit nhỏ nhất trong Kubernetes. Nó là một logical collection của một hoặc nhiều container được scheduled cùng nhau, và collection có thể started, stopped, or rescheduled như một unit of work duy nhất.

Ngoài ra, trong multi-worker Kubernetes cluster, network traffic giữa client users và các containerized applications deploy trong Pods được xử lý trực tiếp bởi các worker nodes thay vì được định tuyến qua các node control plane.

Worker Node Components

Một worker node có các thành phần sau:

• Container Runtime

• Node Agent – kubelet

• Proxy – kube-proxy

• Add-ons for DNS, Dashboard user interface, cluster-level monitoring and logging.

Worker Node Components: Container Runtime

Mặc dù Kubernetes được mô tả là “container orchestration engine”, nhưng nó thiếu khả năng xử lý và vận hành trực tiếp các container. Để quản lý vòng đời của một container, Kubernetes yêu cầu một container runtime trên node nơi một Pod và các container của nó sẽ được scheduled. Runtimes là điều kiện trên tất cả các node của một cụm Kubernetes, cả control plane và worker. Kubernetes hỗ trợ nhiều container runtimes:

• CRI-OA lightweight container runtime for Kubernetes, supporting quay.io and Docker Hub image registries.

• containerdA simple, robust, and portable container runtime.

• Docker EngineA popular and complex container platform which uses containerd as a container runtime.

• Mirantis Container RuntimeFormerly known as the Docker Enterprise Edition.

Worker Node Components: Node Agent – kubelet

Kubelet là một agent chạy trên mỗi node, control plane và workers, và giao tiếp với control plane. Nó nhận Pod definitions, chủ yếu từ API Server, và tương tác với container runtime trên nút để chạy các container associated với Pod. Nó cũng giám sát health và resources của các container đang chạy.

Kubelet kết nối với container runtimes thông qua một plugin based interface – Container Runtime Interface (CRI). CRI bao gồm các protocol buffers, gRPC API, libraries,additional specifications và tools. Để connect với interchangeable container runtimes, kubelet sử dụng CRI shim, một ứng dụng cung cấp một lớp trừu tượng giữa kubelet và container runtime.

Như được hiển thị ở trên, kubelet hoạt động như một máy khách grpc kết nối với CRI shim hoạt động như là một máy chủ grpC để thực hiện các container và image operations. CRI implements hai services: ImageService và RuntimeService. ImageService chịu trách nhiệm cho tất cả các hoạt động liên quan đến image, trong khi RuntimeService chịu trách trách nhiệm về tất cả hoạt động có liên quan tới Pod và container.

Worker Node Components: kubelet – CRI shims

Ban đầu, Kubelet chỉ hỗ trợ một vài container runtimes, đầu tiên là Docker Engine, tiếp theo là rkt, thông qua một mô hình giao diện đặc biệt được tích hợp trực tiếp vào mã nguồn của Kubelet. Tuy nhiên, cách tiếp cận này không nhằm mục đích kéo dài mãi mãi mặc dù nó đặc biệt có lợi cho Docker. Với thời gian, Kubernetes bắt đầu di chuyển hướng tới một cách tiếp cận chuẩn hóa để tích hợp container runtimes bằng cách giới thiệu CRI. Kubernetes đã áp dụng một phương pháp phân tách và linh hoạt để tích hợp với các container runtimes khác nhau mà không cần phải biên dịch lại mã nguồn. Bất kỳ container runtimes nào implements CRI có thể được sử dụng bởi Kubernetes để quản lý container.

Shims là Container Runtime Interface (CRI) implementations, interfaces hoặc adapters, specific cho mỗi container runtime được Kubernetes hỗ trợ. Một số ví dụ của CRI shims:

• cri-containerd: cho phép các container được tạo và quản lý trực tiếp với containerd theo yêu cầu của kubelet:

• CRI-O cho phép sử dụng Open Container Initiative (OCI) compatible runtime với Kubernetes, chẳng hạn như runC:

• dockershim và cri-dockerd: Trước khi Kubernetes phát hành phiên bản 1.24, dockershim cho phép các container được tạo ra và quản lý bằng cách gọi công cụ Docker và internal runtime containerd. Do sự phổ biến của Docker Engine, shim này đã là giao diện mặc định được sử dụng bởi kubelet. Tuy nhiên, bắt đầu với bản phát hành Kubernetes v1.24, dockershim không còn được duy trì bởi dự án Kubernettes, specific code của nó được loại bỏ khỏi mã nguồn kubelet, do đó sẽ không được hỗ trợ bởi kubelet node agent của kubernetes nữa. Kết quả là, Docker, Inc., và Mirantis đã đồng ý giới thiệu và duy trì một adapter thay thế, cri-dockerd sẽ đảm bảo rằng Docker Engine sẽ tiếp tục là một tùy chọn chạy container cho Kubernetes, ngoài Mirantis Container Runtime (MCR). Việc giới thiệu cri-dockerd cũng đảm bảo rằng cả Docker Engine và MCR đều tuân theo cùng một phương pháp tích hợp tiêu chuẩn như CRI-compatible runtimes.

Worker Node Components: Proxy – kube-proxy

Kube-proxy là network agent chạy trên node, control plane và workers, chịu trách nhiệm dynamic updates và duy trì tất cả các quy tắc mạng trên node. Nó abstracts các chi tiết của Pods networking và forwards connection requests đến các container trong Pods.

Kube-proxy chịu trách nhiệm chuyển tiếp TCP, UDP, và SCTP stream hoặc chuyển tiếp ngẫu nhiên qua một tập hợp các Pod backends của một ứng dụng, và nó implements forwarding rules được định nghĩa bởi người dùng thông qua các Service API objects.

Worker Node Components: Add-ons

Add-ons là các tính năng và chức năng của cluster chưa có trong Kubernetes, do đó được thực hiện thông qua các services và pods của bên thứ ba.

• DNSCluster DNS is a DNS server required to assign DNS records to Kubernetes objects and resources.

• Dashboard A general purpose web-based user interface for cluster management.

• Monitoring Collects cluster-level container metrics and saves them to a central data store.

• Logging Collects cluster-level container logs and saves them to a central log store for analysis.

Networking Challenges

Decoupled microservices based applications thuộc rất nhiều vào kết nối mạng để bắt chước sự kết nối chặt chẽ từng có trong thời kỳ monolithic. Networking, nói chung, không phải là phần dễ hiểu và thực hiện. Kubernetes networking cũng không phải là ngoại lệ – là một containerized microservices orchestrator, cần phải giải quyết một vài networking challenges:

• Giao tiếp container-to-container bên trong Pods

• Giao tiếp Pod-to-Pod trên cùng một node và giữa các cluster.

• Giao tiếp Service-to-Pod trong cùng một namespace và giữa các cluster namespaces

• Giao tiếp External-to-Service cho clients các ứng dụng trong cluster

Tất cả những networking challenges này phải được giải quyết trước khi triển khai một cụm Kubernetes.

Container-to-Container Communication Inside Pods

Bằng cách sử dụng các tính năng ảo hoá lõi của hệ điều hành máy chủ, container runtime tạo ra một không gian mạng riêng biệt cho mỗi container nó khởi động. Trên Linux, không gian mạng bị cô lập này được gọi là network namespace. Network namespace có thể được chia sẻ giữa các container, hoặc với hệ điều hành máy chủ.

Khi một nhóm các container được định nghĩa bởi một Pod được start, một infrastructure đặc biệt Pause container được khởi tạo bởi Container Runtime với mục đích duy nhất là tạo ra một network namespace cho Pod. Tất cả các container bổ sung, được tạo ra thông qua yêu cầu của người dùng, chạy bên trong Pod sẽ chia sẻ Pause container’s network namespace để chúng có thể nói chuyện với nhau thông qua localhost.

Pod-to-Pod Communication Across Nodes

Trong một cụm Kubernetes, Pods, nhóm các container, được scheduled trên các node theo một cách gần như không thể đoán trước được. Không quan tâm host node nào, Pods sẽ có thể giao tiếp với tất cả các Pod khác trong cụm mà không cần thực hiện Network Address Translation (NAT). Đây là một yêu cầu cơ bản của bất kỳ networking implementation nào trong Kubernetes.

Mô hình mạng Kubernetes nhằm giảm sự phức tạp, và nó coi Pods như là VM trên một mạng, nơi mà mỗi VM được trang bị một network interface – do đó mỗi Pod nhận được một địa chỉ IP riêng biệt. Mô hình này được gọi là “IP-per-Pod” và đảm bảo giao tiếp Pod-to-Pod, giống như VM có thể giao tiếp với nhau trên cùng một mạng.

Chúng ta đừng quên về các containers. Chúng chia sẻ Pod’s network namespace và phải phối hợp việc gán cổng bên trong Pod giống như các ứng dụng trên máy ảo, tất cả có thể giao tiếp với nhau trên localhost – trong Pod. Tuy nhiên, các container được tích hợp với mô hình mạng Kubernetes thông qua việc sử dụng Container Network Interface (CNI) được hỗ trợ bởi các CNI plugins. CNI là một tập hợp các thông số kỹ thuật và thư viện cho phép các plugin cấu hình mạng cho các container. Trong khi có một vài plugin cốt lõi, hầu hết các plugin CNI là các 3rd-party Software Defined Networking (SDN) solutions implementing mô hình mạng Kubernetes. Ngoài việc giải quyết yêu cầu cơ bản của mô hình mạng, một số giải pháp mạng cung cấp hỗ trợ cho Network Policies. Flannel, Weave, Calico là một vài trong số các giải pháp SDN cho các cụm Kubernetes.

Container runtime offloads việc gán IP cho CNI, và được kết nối với plugin cấu hình cơ bản như Bridge hoặc MACvlan để lấy địa chỉ IP. Nếu plugin tương ứng cung cấp địa chỉ IP, CNI sẽ chuyển nó trở lại container runtime.

Để biết thêm chi tiết, bạn có thể xem thêm Kubernetes documentation.

External-to-Pod Communication

Một containerized application được triển khai trong Pods bên trong một cụm Kubernetes có thể yêu cầu khả năng truy cập từ bên ngoài. Kubernetes cho phép khả năng truy cập bên ngoài thông qua Services, các encapsulations phức tạp của các network routing rule definitions được lưu trữ trong iptables trên các cluster nodes và được thực hiện bởi các kube-proxy agents. Bằng cách exposing services với thế giới bên ngoài với sự giúp đỡ của kube-proxy, các ứng dụng trở nên có thể truy cập từ bên ngoài cụm thông qua một virtual IP và dedicated port number.