- vừa được xem lúc

Pod Lifecycle trong Kubernetes

0 0 18

Người đăng: Đình Tài

Theo Viblo Asia

1. Giới thiệu

Trong bài viết này, chúng ta sẽ tìm hiểu về Pod Lifecycle trong Kubernetes. Để hiểu rõ hơn về Pod Lifecycle, chúng ta cần nắm vững các khái niệm liên quan như Pod Lifetime, Pod Phase, Container States, Container Restart Policy, Pod Conditions, Container Probes và Termination of Pods.

Pod Lifecycle là quá trình từ khi một Pod được tạo đến khi nó bị kết thúc. Việc nắm vững Pod Lifecycle giúp người quản trị Kubernetes có thể quản lý, giám sát và tối ưu hóa hiệu suất của hệ thống một cách hiệu quả.

Trong các chương tiếp theo, chúng ta sẽ cùng tìm hiểu chi tiết về từng khái niệm liên quan đến Pod Lifecycle.

2. Pod Lifetime

2.1. Giới thiệu về Pod Lifetime

Pod Lifetime là thời gian mà một Pod tồn tại trong Kubernetes, bắt đầu từ khi Pod được tạo và kết thúc khi Pod bị xóa hoặc kết thúc. Trong quá trình này, Pod được tạo ra, gán một ID duy nhất (UID), và lên lịch chạy trên các Node trong hệ thống cho đến khi bị kết thúc hoặc xóa.

Pod được xem như một thực thể tạm thời hoặc "ephemeral" trong Kubernetes, có nghĩa là chúng không được xem như là đối tượng bền vững và có thể bị xóa hoặc thay thế bất cứ lúc nào. Khi một Pod bị xóa, mọi tài nguyên liên quan đến Pod đó (ví dụ như Volume hoặc Network) cũng sẽ bị xóa và không thể khôi phục lại.

Pod Lifetime được quản lý và điều khiển bởi Kubernetes Controllers, những thành phần của hệ thống Kubernetes được thiết kế để giám sát, quản lý và duy trì các Pod. Các Controllers này giúp cho việc quản lý và triển khai ứng dụng trên Kubernetes dễ dàng hơn và đảm bảo sự ổn định của hệ thống.

2.2. Các yếu tố ảnh hưởng đến Pod Lifetime

Các yếu tố ảnh hưởng đến Pod Lifetime bao gồm:

  1. Restart Policy: Restart Policy được cấu hình trong Pod để quy định hành vi của Pod khi một container bên trong nó kết thúc hoặc bị lỗi. Restart Policy có thể là "Always" (luôn khởi động lại), "OnFailure" (chỉ khởi động lại khi container bị lỗi), hoặc "Never" (không bao giờ khởi động lại). Policy này sẽ ảnh hưởng đến thời gian Pod tồn tại.
  2. Tình trạng của Node: Nếu một Node bị lỗi hoặc bị xóa khỏi hệ thống, các Pod được lên lịch chạy trên Node đó sẽ bị xóa hoặc phải được chuyển sang Node khác, điều này cũng ảnh hưởng đến Pod Lifetime.
  3. Thiếu tài nguyên: Pod có thể bị đẩy ra khỏi Node hiện tại nếu Node đó thiếu tài nguyên như bộ nhớ hoặc CPU, hoặc nếu Node phải được bảo trì. Việc này có thể làm gián đoạn Pod và ảnh hưởng đến Pod Lifetime.
  4. Các Controllers quản lý Pod: Kubernetes sử dụng các Controllers để quản lý và tự động điều chỉnh số lượng Pod, điều này cũng ảnh hưởng đến Pod Lifetime. Nếu số lượng Pod được quản lý bởi Controller bị giảm hoặc tăng, Pod Lifetime có thể bị ảnh hưởng.
  5. Lỗi và sự cố khác: Một số lỗi và sự cố khác như lỗi mạng, lỗi cấu hình hoặc lỗi ứng dụng có thể dẫn đến việc Pod bị xóa hoặc kết thúc sớm hơn dự kiến, ảnh hưởng đến Pod Lifetime.

Bằng cách hiểu rõ các yếu tố ảnh hưởng đến Pod Lifetime, người quản trị Kubernetes có thể đưa ra các quyết định và tùy chỉnh hệ thống sao cho phù hợp với nhu cầu và mục tiêu của ứng dụng.

3. Pod phase

3.1. Giới thiệu về Pod Phase

Pod Phase là trạng thái hiện tại của một Pod trong vòng đời của nó. Đây là một trừu tượng cấp cao, tổng quát của trạng thái Pod, giúp người quản trị dễ dàng quan sát và theo dõi quá trình hoạt động của Pod. Pod Phase không cung cấp chi tiết về trạng thái của từng container bên trong Pod, nhưng nó cho phép quản trị viên nắm bắt được tình hình chung của Pod đó.

3.2. Các trạng thái của Pod Phase

Có năm trạng thái cơ bản trong Pod Phase:

  1. Pending: Pod đã được chấp nhận bởi hệ thống Kubernetes nhưng chưa được chạy trên một Node nào. Trong giai đoạn này, hệ thống có thể đang chuẩn bị các tài nguyên cần thiết cho Pod, chẳng hạn như tải xuống các container image.
  2. Running: Pod đã được lên lịch chạy trên một Node và tất cả các container đã được tạo. Ít nhất một container đang hoạt động, hoặc đang bắt đầu hoặc kết thúc.
  3. Succeeded: Tất cả các container trong Pod đã terminated thành công và không còn hoạt động. Pod sẽ không chạy lại sau khi đạt được trạng thái này.
  4. Failed: Tất cả các container trong Pod đã terminated, và ít nhất một container đã terminated với trạng thái thất bại. Trạng thái thất bại có nghĩa là container đã thoát khỏi chương trình với mã lỗi không bằng 0 (có lỗi xảy ra).
  5. Unknown: Vì một số lý do, không thể truy vấn được trạng thái của Pod, thường là do lỗi giao tiếp với Node mà Pod đang chạy.

Lưu ý: Khi một Pod đang bị xóa, nó sẽ được hiển thị dưới dạng Terminating (đang được xóa) trong một số lệnh kubectl. Trạng thái Terminating này không phải là một trong các giai đoạn của Pod. Pod được cấp một khoảng thời gian để kết thúc an toàn, mặc định là 30 giây. Bạn có thể sử dụng flag --force để tắt Pod một cách bắt buộc.

Kể từ phiên bản Kubernetes 1.27, kubelet sẽ chuyển trạng thái của các Pod bị xóa sang Failed hoặc Succeeded tùy thuộc vào trạng thái thoát của các container trong Pod trước khi xóa Pod đó khỏi API server.

Nếu một Node bị hỏng hoặc mất kết nối với phần còn lại của cluster, Kubernetes sẽ áp dụng một policy để thiết lập phase cho tất cả các Pod trên Node bị mất thành Failed.

Bằng cách nắm rõ các trạng thái của Pod Phase, người quản trị có thể theo dõi và giám sát hiệu quả quá trình hoạt động của Pod trong Kubernetes, giúp họ đưa ra các quyết định phù hợp để đảm bảo ổn định và hiệu năng của hệ thống.

4. Container States

4.1. Giới thiệu về Container States

Trong khi Pod Phase cung cấp cái nhìn tổng quát về trạng thái của Pod, Container States cung cấp thông tin chi tiết hơn về trạng thái của từng container bên trong Pod. Mỗi container có thể có một trạng thái riêng biệt, phụ thuộc vào tình hình chạy của nó. Việc nắm vững Container States giúp người quản trị dễ dàng theo dõi, giám sát và xử lý các vấn đề liên quan đến container trong hệ thống Kubernetes.

4.2. Các trạng thái của Container States

Có ba trạng thái cơ bản trong Container States:

  1. Waiting: Container đang chờ được chạy. Có thể có nhiều lý do khiến container ở trạng thái này, chẳng hạn như đang tải xuống container image, hoặc đang chờ tài nguyên từ hệ thống. Trong trạng thái này, bạn có thể thấy thông tin về lý do chờ và thông báo lỗi (nếu có).
  2. Running: Container đang chạy và hoạt động. Trong trạng thái này, bạn có thể thấy thông tin về thời điểm bắt đầu chạy của container và thông tin về cấu hình của nó.
  3. Terminated: Container đã chạy xong và không còn hoạt động. Container có thể kết thúc với trạng thái thành công hoặc thất bại. Trong trạng thái này, bạn có thể thấy thông tin về thời điểm bắt đầu và kết thúc của container, lý do kết thúc và mã lỗi (nếu có).

Bằng cách nắm rõ các trạng thái của Container States, người quản trị có thể theo dõi và giám sát hiệu quả quá trình hoạt động của từng container trong hệ thống Kubernetes, giúp họ đưa ra các quyết định phù hợp để đảm bảo ổn định và hiệu năng của hệ thống.

5. Container Restart Policy

5.1. Giới thiệu về Container Restart Policy

Container Restart Policy là một cài đặt quan trọng trong Kubernetes, quy định cách thức và điều kiện để container được khởi động lại khi chúng kết thúc. Restart Policy giúp đảm bảo tính ổn định và sẵn sàng của ứng dụng bằng cách tự động khởi động lại container khi cần thiết. Tùy thuộc vào yêu cầu và mục tiêu của ứng dụng, người quản trị có thể chọn một trong số các container restart policy khác nhau.

5.2. Các Container Restart Policy

Có ba container restart policy cơ bản trong Kubernetes:

  1. Always: Dưới policy này, container sẽ luôn được khởi động lại khi nó kết thúc, bất kể kết quả là thành công hay thất bại. Đây là policy mặc định cho các container trong Kubernetes. policy này phù hợp với các ứng dụng cần luôn sẵn sàng và hoạt động.
  2. OnFailure: Dưới policy này, container chỉ được khởi động lại khi nó kết thúc với trạng thái thất bại (mã lỗi không bằng 0). Nếu container kết thúc thành công, nó sẽ không được khởi động lại. policy này phù hợp với các ứng dụng chỉ cần khôi phục khi có sự cố.
  3. Never: Dưới policy này, container sẽ không bao giờ được khởi động lại khi nó kết thúc, bất kể kết quả là thành công hay thất bại. policy này phù hợp với các ứng dụng không cần tính sẵn sàng cao hoặc các tác vụ một lần chạy.

Bằng cách nắm rõ các container restart policy, người quản trị có thể cấu hình và tùy chỉnh hệ thống Kubernetes sao cho phù hợp với nhu cầu và mục tiêu của ứng dụng, đảm bảo ổn định và hiệu năng của hệ thống.

6. Pod Conditions

6.1. Giới thiệu về Pod Conditions

Pod Conditions là một tập hợp các thông tin về các điều kiện hiện tại của một Pod. Các điều kiện này mô tả chi tiết hơn về tình trạng của Pod so với Pod Phase, cho phép người quản trị nắm bắt các vấn đề hoặc điều kiện đặc biệt mà Pod đang gặp phải. Pod Conditions được biểu diễn dưới dạng một mảng các đối tượng, mỗi đối tượng bao gồm tên điều kiện, trạng thái (True, False hoặc Unknown), một thông báo tùy chọn và một dấu thời gian cho thời điểm điều kiện được cập nhật gần nhất.

6.2. Các điều kiện thông dụng trong Pod Conditions

Một số Pod Conditions thông dụng bao gồm:

  1. PodScheduled: Điều kiện này cho biết Pod đã được lên lịch chạy trên một Node hay chưa. Trạng thái sẽ là True nếu Pod đã được lên lịch, False nếu không được lên lịch và Unknown nếu không thể xác định được trạng thái.
  2. Ready: Điều kiện này cho biết Pod đã sẵn sàng để xử lý yêu cầu hay chưa. Trạng thái sẽ là True nếu tất cả các container trong Pod đang hoạt động và sẵn sàng xử lý yêu cầu, False nếu không sẵn sàng và Unknown nếu không thể xác định được trạng thái.
  3. ContainersReady: Điều kiện này tương tự như điều kiện Ready, nhưng chỉ áp dụng cho từng container trong Pod. Trạng thái sẽ là True nếu container đang hoạt động và sẵn sàng xử lý yêu cầu, False nếu không sẵn sàng và Unknown nếu không thể xác định được trạng thái.
  4. Initialized: Điều kiện này cho biết tất cả các container khởi tạo trong Pod đã hoàn thành thành công hay chưa. Trạng thái sẽ là True nếu tất cả các container khởi tạo đã hoàn thành, False nếu chưa hoàn thành và Unknown nếu không thể xác định được trạng thái.

Bằng cách nắm rõ các Pod Conditions, người quản trị có thể theo dõi và giám sát hiệu quả quá trình hoạt động của Pod trong hệ thống Kubernetes, giúp họ đưa ra các quyết định phù hợp để đảm bảo ổn định và hiệu năng của hệ thống.

7. Container Probes

7.1. Giới thiệu về Container Probes

Container Probes là một cơ chế trong Kubernetes giúp kiểm tra trạng thái của các container bên trong Pod. Có ba loại Container Probes được sử dụng để kiểm tra và xác định trạng thái của container, đảm bảo container hoạt động ổn định và sẵn sàng phục vụ yêu cầu. Việc sử dụng Container Probes giúp người quản trị phát hiện và xử lý các vấn đề liên quan đến container một cách nhanh chóng và hiệu quả.

7.2. Các loại Container Probes

Có ba loại Container Probes chính:

  1. Liveness Probe: Liveness Probe kiểm tra xem container có đang hoạt động không. Nếu Liveness Probe thất bại, container sẽ bị khởi động lại theo container restart Policy). Liveness Probe giúp đảm bảo rằng container vẫn đang hoạt động và không bị treo hay gặp vấn đề nghiêm trọng.
  2. Readiness Probe: Readiness Probe kiểm tra xem container có sẵn sàng phục vụ yêu cầu không. Nếu Readiness Probe thất bại, container sẽ không nhận được yêu cầu từ các dịch vụ hay tải cân bằng tải (Load Balancer). Readiness Probe giúp đảm bảo rằng container chỉ nhận yêu cầu khi thực sự sẵn sàng xử lý chúng.
  3. Startup Probe: Startup Probe kiểm tra xem container có khởi động thành công không. Nếu Startup Probe thất bại trong một khoảng thời gian cho phép, container sẽ bị khởi động lại. Startup Probe giúp xác định liệu container có gặp vấn đề khi khởi động không, giúp người quản trị đưa ra các biện pháp khắc phục kịp thời.

Bằng cách sử dụng và cấu hình phù hợp với các Container Probes, người quản trị có thể đảm bảo hiệu quả hoạt động của các container trong hệ thống Kubernetes, đồng thời nâng cao khả năng giám sát và xử lý các vấn đề liên quan đến container.

8. Termination of Pods

8.1. Giới thiệu về Termination of Pods

Termination of Pods là quá trình kết thúc hoạt động của một Pod trong hệ thống Kubernetes. Việc kết thúc Pod có thể xảy ra do nhiều nguyên nhân khác nhau, như việc hoàn thành công việc, yêu cầu từ người quản trị, hoặc lỗi phần cứng trên node mà Pod đang chạy. Khi một Pod bị kết thúc, tất cả các container bên trong Pod cũng sẽ dừng hoạt động và các tài nguyên liên quan sẽ được giải phóng.

Vì Pod đại diện cho các tiến trình đang chạy trên các node trong cluster, do đó rất quan trọng để cho phép các tiến trình đó kết thúc một cách an toàn khi chúng không còn cần thiết (thay vì bị dừng đột ngột bằng tín hiệu KILL và không có cơ hội để dọn dẹp). Mục tiêu thiết kế là cho phép yêu cầu xóa và biết khi quá trình kết thúc, nhưng cũng cho phép đảm bảo rằng việc xóa sẽ được hoàn thành.

Khi yêu cầu xóa một Pod, cluster ghi lại và theo dõi khoảng thời gian an toàn trước khi cho phép Pod bị tắt một cách bắt buộc. Với việc theo dõi đó, kubelet cố gắng kết thúc Pod một cách an toàn. Thông thường, container runtime sẽ gửi một tín hiệu TERM đến main process trong mỗi container. Nhiều container runtime tuân thủ giá trị STOPSIGNAL được định nghĩa trong container image và gửi tín hiệu này thay vì TERM. Sau khi hết thời gian an toàn, tín hiệu KILL được gửi đến bất kỳ process nào còn lại và Pod được xóa khỏi API Server. Nếu kubelet hoặc dịch vụ quản lý container runtime bị khởi động lại trong khi đang chờ quá trình kết thúc, cluster sẽ thử lại từ đầu.

8.2. Quá trình Termination of Pods

Quá trình kết thúc của một Pod bao gồm các bước sau:

  1. Người dùng (hoặc một thành phần tự động hóa nào đó) gửi yêu cầu xóa Pod đến API Server của Kubernetes.
  2. API Server cập nhật trạng thái của Pod với thời điểm dự kiến xóa và không chấp nhận yêu cầu mới cho Pod này.
  3. Kubelet nhận thông báo về yêu cầu xóa Pod và bắt đầu quá trình kết thúc an toàn. Mỗi container trong Pod sẽ nhận được tín hiệu TERM (hoặc tín hiệu được chỉ định bởi STOPSIGNAL) cho main process của container.
  4. Các container bắt đầu dọn dẹp, lưu lại trạng thái hiện tại, hoàn thành các công việc đang chạy và dừng lại một cách an toàn.
  5. Sau khi hết thời gian an toàn, kubelet sẽ gửi tín hiệu KILL đến các process còn lại trong container và chúng bị dừng đột ngột.
  6. Kubelet thông báo cho API Server rằng Pod đã bị xóa khỏi node. API Server sau đó xóa Pod khỏi cấu trúc dữ liệu của nó và Pod không còn xuất hiện trong danh sách các Pod đang hoạt động.

Quá trình kết thúc Pod được thiết kế để đảm bảo rằng các tiến trình trong container có đủ thời gian để dừng lại một cách an toàn và dọn dẹp tài nguyên trước khi bị tắt hoàn toàn. Việc tuân thủ quá trình này giúp đảm bảo tính ổn định và hiệu suất của hệ thống Kubernetes.

8.3. Forced Pod Termination

Trong một số trường hợp, có thể cần phải buộc kết thúc một Pod một cách nhanh chóng hơn so với quá trình kết thúc an toàn thông thường. Điều này có thể xảy ra khi một Pod gây ra vấn đề cho hệ thống hoặc khi cần giải phóng tài nguyên của node nhanh chóng. Forced Pod termination cho phép người dùng (hoặc một thành phần tự động hóa) buộc kết thúc một Pod mà không cần chờ đợi quá trình kết thúc an toàn.

Để thực hiện việc buộc kết thúc một Pod, bạn có thể sử dụng lệnh kubectl delete với tùy chọn --grace-period=0:

kubectl delete pod <pod-name> --grace-period=0

Khi sử dụng tùy chọn này, các bước trong quá trình kết thúc Pod sẽ bị bỏ qua và kubelet sẽ gửi tín hiệu KILL ngay lập tức đến tất cả các process trong các container của Pod. Điều này dẫn đến việc dừng lại đột ngột của các tiến trình và không có thời gian dành cho việc dọn dẹp tài nguyên hoặc lưu trạng thái. Forced Pod termination nên được sử dụng một cách thận trọng, chỉ khi cần thiết, để đảm bảo tính ổn định và hiệu suất của hệ thống Kubernetes.

8.4. Garbage Collection of Pods

Sau khi một Pod bị xóa khỏi hệ thống, có thể vẫn còn lại một số tài nguyên không được dọn dẹp một cách tự động, như là các tập tin nhật ký, tài nguyên lưu trữ tạm thời hoặc các đối tượng Kubernetes liên quan. Để giải quyết vấn đề này, Kubernetes sử dụng một quá trình gọi là "garbage collection" để dọn dẹp các tài nguyên không còn sử dụng.

Garbage collection hoạt động theo các bước sau:

  • Kubelet trên mỗi node sẽ kiểm tra định kỳ các tài nguyên không còn sử dụng, chẳng hạn như các container đã kết thúc, tập tin nhật ký cũ hoặc tài nguyên lưu trữ tạm thời.
  • Kubelet xác định các tài nguyên không còn sử dụng dựa trên các tiêu chí như thời gian tồn tại, dung lượng lưu trữ hoặc số lượng đối tượng.
  • Kubelet dọn dẹp các tài nguyên không còn sử dụng một cách an toàn, giải phóng không gian đĩa và tài nguyên hệ thống.

Đối với đối tượng Kubernetes, các nhà phát triển có thể sử dụng "Owner References" để liên kết các đối tượng con với đối tượng cha của chúng. Khi đối tượng cha bị xóa, các đối tượng con cũng sẽ được dọn dẹp tự động bởi garbage collector.

Một số tài nguyên, như Persistent Volumes (PV) và Persistent Volume Claims (PVC), không được dọn dẹp tự động. Trong trường hợp này, người dùng phải dọn dẹp chúng một cách thủ công sau khi chúng không còn sử dụng nữa.

Garbage collection đảm bảo rằng hệ thống Kubernetes hoạt động hiệu quả và giữ cho môi trường sạch sẽ, giúp giảm thiểu rủi ro liên quan đến việc sử dụng tài nguyên không cần thiết và giải phóng không gian đĩa cho các tài nguyên quan trọng hơn.

9. Kết luận

Trong bài viết này, chúng ta đã tìm hiểu về các khái niệm quan trọng liên quan đến vòng đời Pod của Kubernetes, bao gồm Pod Lifetime, Pod Phase, Container States, Container Restart Policy, Pod Conditions, Container Probes và Termination of Pods. Việc nắm vững các khái niệm này giúp người quản trị có thể vận hành và giám sát hiệu quả hệ thống Kubernetes, đồng thời đưa ra các quyết định phù hợp để đảm bảo ổn định và hiệu năng của hệ thống.

Kubernetes là một công cụ mạnh mẽ và linh hoạt, hỗ trợ người quản trị trong việc triển khai, mở rộng và quản lý các ứng dụng container hóa. Bằng cách hiểu rõ về vòng đời Pod và các khái niệm liên quan, người quản trị sẽ có khả năng tận dụng tối đa sức mạnh của Kubernetes và đảm bảo hiệu quả hoạt động của hệ thống.

10. Tài liệu tham khảo

  1. Kubernetes Authors. (2021). Kubernetes Documentation. Truy cập từ https://kubernetes.io/docs/home/
  2. Burns, B., Beda, J., & Hightower, K. (2017). Kubernetes: Up and Running: Dive into the Future of Infrastructure. O'Reilly Media, Inc.
  3. Miles, L., & Mui, A. (2019). Mastering Kubernetes: Level up your container orchestration skills with Kubernetes to build, run, secure, and observe large-scale distributed apps, 3rd Edition. Packt Publishing.
  4. Kubernetes Authors. (2021). Pod Lifecycle. Truy cập từ https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/
  5. Kubernetes Authors. (2021). Container Probes. Truy cập từ https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
  6. Kubernetes Authors. (2021). Termination of Pods. Truy cập từ https://kubernetes.io/docs/concepts/workloads/pods/pod/#termination-of-pods

Bình luận

Bài viết tương tự

- vừa được xem lúc

Phần 1: Giới thiệu về Kubernetes

Kubernetes là gì. Trang chủ: https://kubernetes.io/. Ai cần Kubernetes.

0 0 100

- vừa được xem lúc

Thực hành K8S trên Google Cloud

Kubernetes (K8S) trở nên quá phổ biến ở thời điểm hiện tại, ai cũng nói về nó. Trong bài hôm nay mình sẽ không đi quá nhiều vào các định nghĩa, mà đi thẳng vào thực tế để mọi người dễ hình dung.

0 0 34

- vừa được xem lúc

Kubernetes best practices - Liveness và Readiness Health checks

Mở đầu. Kubernetes cung cấp cho bạn một framework để chạy các hệ phân tán một cách mạnh mẽ.

0 0 49

- vừa được xem lúc

Kubernetes - deployment.yaml explained

Trong bài trước, mình có giới thiệu chạy các câu lệnh K8S bằng Command Line. Để tạo 1 deloyment đơn giản chỉ cần chạy lệnh.

0 0 91

- vừa được xem lúc

Tìm hiểu cơ bản về Kubernetes - K8s (Part 2): Minikube

Lời mở đầu. .

0 0 47

- vừa được xem lúc

ETCD - Bộ não của Kubernetes và cách cài đặt cụm ETCD Cluster (High Availability)

Hello anh em, sau vài ngày nghiên cứu đọc lại liệu cũng như cài cắm thủ công đủ thể loại, với vô số lỗi fail thì mình cũng cài đặt thành công cụm etcd cluster một cách thủ công. Trước giờ chuyên tạo c

0 0 44