Tài liệu

• 1: Tài liệu Kubernetes
• 1.1: Các phiên bản được hỗ trợ của tài liệu Kubernetes
• 2: Bắt đầu với Kubernetes
• 2.1: Môi trường Production
• 2.1.1: Cài đặt Kubernetes với các công cụ triển khai
• 2.1.1.1: Khởi tạo cụm với kubeadm
• 2.1.1.1.1: Cài đặt kubeadm
• 2.1.1.1.2: Thiết lập một cụm etcd có tính Sẵn sàng cao (High Availability) với kubeadm
• 2.2: Một số cách thức cài đặt tốt
• 3: Các khái niệm
• 3.1: Tổng quan
• 3.1.1: Kubernetes là gì
• 3.2: Kiến Trúc Cluster
• 3.2.1: Các khái niệm nền tảng của Cloud Controller Manager
• 3.3: Containers
• 3.3.1: Các biến môi trường của Container
• 3.3.2: Container Lifecycle Hooks
• 4: Tasks
• 4.1: Cài đặt các công cụ
• 4.1.1: Cài đặt và cấu hình kubectl
• 4.1.2: Cài đặt Minikube
• 4.2: Cấu hình Pods và Containers
• 4.2.1: Cấp phát tài nguyên bộ nhớ cho Containers và Pods
• 5: Tutorials
• 5.1: Học kiến thức cơ bản về Kubernetes
• 5.1.1: Tạo một Cluster
• 5.1.1.1: Sử dụng Minikube để tạo một Cluster
• 5.1.1.2: Hướng dẫn tương tác - Tạo một Cluster
• 5.1.2: Triển khai một ứng dụng
• 5.1.2.1: Sử dụng kubectl để triển khai ứng dụng
• 5.1.2.2: Hướng dẫn tương tác - Triển khai một ứng dụng
• 5.1.3: Khám phá ứng dụng
• 5.1.3.1: Khám Phá Pods Và Nodes
• 5.1.3.2: Hướng dẫn tương tác - Khám phá ứng dụng
• 6: Tài liệu tham khảo
• 6.1: Thuật ngữ chuẩn hóa
• 6.2: kubectl Cheat Sheet
• 7: Đóng góp cho Kubernetes

1 - Tài liệu Kubernetes

1.1 - Các phiên bản được hỗ trợ của tài liệu Kubernetes

Trang web này lưu tài liệu của phiên bản hiện tại và bốn phiên bản trước của Kubernetes.

2 - Bắt đầu với Kubernetes

Ở mục này chúng ta sẽ liệt kê ra những cách khác nhau để cài đặt và sử dụng Kubernetes. Khi cài đặt Kubernetes, bạn hãy lựa chọn cách thức dựa trên theo những yếu tố như: dễ dàng bảo trì, tính bảo mật, mức độ kiểm soát, tài nguyên sẵn có, cũng như trình độ chuyên môn cần thiết để vận hành và quản lý cluster.

Để triển khai (deploy) Kubernetes cluster ở máy local, trên dịch vụ điện toán đám mây (cloud) hay ở trung tâm dữ liệu của riêng bạn, hãy tải Kubernetes xuống ở đây.

Một số components của Kubernetes như kube-apiserver hoặc kube-proxy có thể được triển khai dưới dạng container images ở trong cluster.

Chúng tôi khuyến khích bạn thực thi components dưới dạng những container images, Kubernetes sẽ quản lý những components đó. Lưu ý, không bao gồm những components có sử dụng container (đặc biệt là kubelet).

Trong trường hợp bạn không muốn tự quản lý Kubernetes cluster, bạn có thể chọn một service quản lý, bao gồm certified platforms. Ngoài ra còn có các giải pháp tiêu chuẩn và tùy chỉnh khác trên nhiều môi trường điện toán đám mây (cloud), hay môi trường một máy chủ (bare metal environment) khác nhau.

Môi trường học tập

Nếu bạn đang ở trong giai đoạn học Kubernetes, bạn có thể sử dụng những công cụ (tools) được hỗ trợ bởi cộng đồng Kubernetes, hoặc những công cụ trong hệ sinh thái để cài đặt Kubernetes cluster trên máy của bạn. Xem thêm.

Môi trường production

Khi đánh giá một giải pháp dành cho môi trường production, bạn cần xem xét những khía cạnh về việc vận hành Kubernetes cluster (hoặc khái niệm trừu trượng của nó) mà bạn muốn tự quản lý, hoặc những phần nào bạn muốn để cho nhà cung cấp quản lý.

Với cluster bạn tự quản lý, công cụ hỗ trợ chính thức để triển khai (deploy) Kubernetes là kubeadm.

Tiếp theo là gì

• Tải Kubernetes
• Tải và cài đặt công cụ (tools) bao gồm kubectl
• Lựa chọn container runtime cho cluster của bạn
• Tìm hiểu một số cách thức cài đặt tốt cho cluster

2.1 - Môi trường Production

Một cụm Kubernetes chất lượng production yêu cầu có sự lên kế hoạch và chuẩn bị. Nếu cụm Kubernetes của bạn dùng để chạy các workload quan trọng, nó phải được cấu hình để có khả năng phục hồi. Trang này giải thích các bước bạn có thể thực hiện để thiết lập một cụm sẵn sàng cho production, hoặc để thúc đẩy một cụm hiện có cho việc sử dụng production. Nếu bạn đã quen thuộc với thiết lập production và muốn những liên kết, hãy bỏ qua đến Tiếp theo là gì.

Những cân nhắc production

Thông thường, một môi trường cụm Kubernetes production có nhiều yêu cầu hơn một môi trường Kubernetes cho học tập, phát triển hoặc thử nghiệm cá nhân. Một môi trường production có thể yêu cầu truy cập an toàn bởi nhiều người dùng, tính khả dụng nhất quán, và các nguồn lực để thích ứng với nhu cầu thay đổi.

Khi bạn quyết định nơi bạn muốn triển khai môi trường Kubernetes production (on-premise hoặc trên cloud) và lượng công việc quản lý bạn muốn đảm nhận hoặc trao cho người khác, hãy xem xét các yêu cầu của bạn đối với cụm Kubernetes bị ảnh hưởng như thế nào bởi các vấn đề sau:

• Tính sẵn sàng: Một môi trường học tập Kubernetes trên một máy có một điểm lỗi duy nhất. Tạo một cụm có tính sẵn sàng cao có nghĩa là phải cân nhắc:

  • Tách control plane khỏi các worker node.
  • Nhân bản các thành phần control plane trên nhiều node.
  • Cân bằng tải lưu lượng tới API server của cụm.
  • Có đủ các worker node sẵn sàng, hoặc có khả năng trở nên khả dụng một cách nhanh chóng khi workload thay đổi.

• Quy mô: Nếu bạn mong muốn môi trường Kubernetes production của mình đáp ứng được một lượng yêu cầu ổn định, bạn có thể thiết lập khả năng đáp ứng bạn cần và hoàn thành. Tuy nhiên, nếu bạn mong muốn đáp ứng nhu cầu tăng theo thời gian hoặc thay đổi đáng kể dựa trên những yếu tố như mùa hoặc sự kiện đặc biệt, bạn cần lập kế hoạch về việc mở rộng quy mô để giảm bớt áp lực tăng lên từ nhiều yêu cầu hơn đối với control plane và các worker node hoặc thu hẹp quy mô để tối ưu tài nguyên không sử dụng.

• Quản lý bảo mật và truy cập: Bạn có đầy đủ các đặc quyền admin trên cụm Kubernetes học tập của mình. Nhưng các cụm chia sẻ với nhiều workload quan trọng, và nhiều hơn một hoặc hai người dùng, yêu cầu một cách tiếp cận tinh tế hơn đối với những ai và những gì có thể truy cập vào các tài nguyên cụm. Bạn có thể sử dụng kiểm soát truy cập dựa trên vai trò (RBAC) và các kỹ thuật bảo mật khác để chắc chắn rằng người dùng và workloads có thể truy cập được tới tài nguyên họ cần trong khi vẫn đảm bảo bảo mật cho worload và cụm máy chủ. Bạn có thể đặt giới hạn lên tài nguyên mà người dùng và workload có thể truy cập bằng cách quản lý các chính sách và tài nguyên container.

Trước khi dựng một môi trường Kubernetes production, cân nhắc chuyển giao một phần hoặc toàn bộ công việc này cho các nhà cung cấp giải pháp Cloud Turnkey Cloud Solutions hoặc các đối tác Kubernetes Partners. Các tùy chọn gồm:

• Serverless: Chỉ cần chạy workload trên thiết bị của bên thứ ba mà không cần quản lý toàn bộ cụm. Bạn sẽ bị tính phí cho những thứ như mức sử dụng CPU, bộ nhớ, và các yêu cầu ổ đĩa.
• Control plane được quản lý: Hãy để nhà cung cấp quản lý quy mô và tính sẵn sàng của control plane trong cụm, cũng như xử lý các bản vá và cập nhật.
• Worker node được quản lý: Cấu hình nhóm các node để đáp ứng nhu cầu của bạn, sau đó nhà cung cấp sẽ đảm bảo rằng những node đó khả dụng và sẵn sàng để thực hiện các cập nhật khi cần thiết.
• Sự tích hợp: Có những nhà cung cấp tích hợp Kubernetes với các dịch vụ khác mà bạn có thể cần, ví dụ kho lưu trữ, container registries, các phương thức xác thực, và những công cụ phát triển.

Liệu bạn tự dựng một cụm Kubernetes production hay làm điều đó với các đối tác, xem những phần dưới đây để đánh giá nhu cầu liên quan tới control plane, các worker node, truy cập người dùng, và các tài nguyên workload cho cụm của bạn.

Thiết lập cụm production

Trong một cụm Kubernetes có chất lượng production, control plane quản lý cụm từ các dịch vụ có thể được trải đều trên nhiều máy tính theo những cách khác nhau. Tuy nhiên, mỗi worker node đại diện cho một thực thể duy nhất được cấu hình để chạy Kubernetes pod.

Control plane trên production

Cụm Kubernetes đơn giản nhất có toàn bộ dịch vụ control plane và worker node chạy trên cùng một máy. Bạn có thể phát triển môi trường đó bằng cách thêm các worker node, như được phản ánh trong sơ đồ được minh họa trong Các thành phần Kubernetes. Nếu cụm có nghĩa là có sẵn trong một khoảng thời gian ngắn hoặc có thể bị loại bỏ nếu có sự cố nghiêm trọng, điều này có thể đáp ứng nhu cầu của bạn.

Tuy nhiên, nếu bạn cần một cụm vĩnh viễn, có mức độ sẵn cao hơn, bạn nên xem xét các cách mở rộng control plane. Theo thiết kế, dịch vụ control plane chạy trên một máy tính đơn là không có tính sẵn sàng cao. Nếu việc giữ cụm được dựng lên và chạy và đảm bảo rằng nó có thể được sửa chữa nếu có sự cố xảy ra là điều quan trọng, Xem xét các bước sau:

• Chọn các công cụ triển khai: Bạn có thể triển khai một control plane bằng các công cụ vi dụ như kubeadm, kops, và kubespray. Xem Cài đặt Kubernetes với những công cụ triển khai để tìm hiểu các mẹo triển khai chất lượng production bằng cách sử dụng từng phương pháp triển khai đó. Những Container Runtimes khác cũng có sẵn để bạn sử dụng cho việc triển khai của mình.
• Quản lý chứng chỉ: Giao tiếp bảo mật giữa các dịch vụ control plane được thực hiện bằng chứng chỉ. Chứng chỉ được tự động tạo trong quá trình triển khai hoặc bạn có thể tạo chúng bằng cách sử dụng cơ quan cấp chứng chỉ của riêng bạn. Xem Chứng chỉ PKI và yêu cầu để biết thêm chi tiết.
• Cấu hình bộ cân bằng tải cho apiserver: Cấu hình bộ cân bằng tải để phân phối các request API bên ngoài tới các instance của dịch vụ apiserver chạy trên các node khác nhau. Xem Tạo Bộ Cân bằng tải bên ngoài để biết thêm chi tiết.
• Phân tách và sao lưu dịch vụ etcd: Các dịch vụ etcd có thể chạy trên cùng các máy với các dịch vụ control plane khác hoặc chạy trên các máy tách biệt, để tăng tính bảo mật và khả dụng. Bởi vì etcd lưu dữ liệu cấu hình của cụm, sao lưu cơ sở dữ liệu etcd nên được thực hiện thường xuyên để đảm bảo rằng bạn có thể sửa chữa cơ sở dữ liệu đó nếu cần. Xem thêm etcd FAQ để biết thêm chi tiết về việc cấu hình và sử dụng etcd. Xem Vận hành các cụm etcd cho Kubernetes và Thiết lập một cụm etcd có tính Sẵn sàng cao với kubeadm để biết thêm chi tiết.
• Tạo nhiều hệ thống control plane: Để có tính sẵn sàng cao, control plane không nên giới hạn trong một máy. Nếu các dịch vụ control plane được chạy bởi một dịch vụ khởi tạo (ví dụ systemd), các dịch vụ nên chạy trên ít nhất ba máy. Tuy nhiên, chạy các dịch vụ control plane dạng pods trong Kubernetes đảm bảo rằng số lượng bản sao dịch vụ mà bạn yêu cầu sẽ luôn có sẵn. Scheduler phải có khả năng chịu lỗi, nhưng không sẵn sàng cao. Một số công cụ triển khai được thiết lập thuật toán đồng thuận Raft để bầu cử leader cho các dịch vụ Kubernetes. Nếu nếu leader biến mất, một dịch vụ khác tự bầu cử chính nó và tiếp quản.
• Trải rộng nhiều zone: Nếu việc duy trì cụm khả dụng mọi lúc là quan trọng, cân nhắc việc tạo một cụm chạy trên nhiều trung tâm dữ liệu, được gọi là zone trên các môi trường đám mây. Nhóm các zone gọi là region. Bằng cách trải rộng một cụm trên nhiều zone trong cùng một region, nó có thể làm tăng cơ hội cho cụm của bạn được tiếp tục hoạt động ngay cả khi một zone trở nên không khả dụng. Xem Chạy trong nhiều zone để biết thêm chi tiết.
• Quản lý các tính năng on-going: Nếu bạn có kế hoạch giữ cụm theo thời gian, có những nhiệm vụ bạn cần làm để duy trì sức khỏe và bảo mật của cụm. Ví dụ, nếu bạn đã cài đặt với kubeadm, có các hướng dẫn để giúp bạn Quản lý Chứng chỉ và Nâng cấp các cụm kubeadm. Xem Quản lý một cụm để biết thêm danh sách các tác vụ quản trị của Kubernetes.

Để tìm hiểu về các tùy chọn có sẵn khi bạn chạy các dịch vụ control plane, xem các trang kube-apiserver, kube-controller-manager, và kube-scheduler. Đối với các ví dụ về control plane có tính sẵn sàng cao, xem Các tùy chọn cho kiến trúc có tính Sẵn sàng cao, Tạo các cụm có tính Sẵn sàng cao với kubeadm, và Vận hành cụm etcd cho Kubernetes. Xem Sao lưu cụm etcd để biến cách tạo kế hoạch sao lưu cho etcd.

Worker node trên production

Workload chất lượng production cần phải có tính đàn hồi và bất kỳ thành phần nào mà chúng phụ thuộc vào cũng phải có tính đàn hồi (ví dụ CoreDNS). Cho dù bạn tự quản lý control plane hay có một nhà cung cấp cloud làm điều đó cho bạn, bạn vẫn cần phải xem xét cách bạn muốn quản lý các worker node (còn gọi một cách đơn giản là node).

• Cấu hình các node: Các node có thể là máy vật lý hay máy ảo. Nếu bạn muốn tạo và quản lý node của riêng bạn, bạn có thể cài đặt một hệ điều hành được hỗ trợ, sau đó thêm và chạy các dịch vụ Node thích hợp. Xem xét:
  • Nhu cầu của workload khi bạn thiết lập các node bằng cách có sẵn bộ nhớ, CPU và tốc độ đĩa và dung lượng lưu trữ phù hợp.
  • Liệu các hệ thống máy tính chung sẽ làm hay bạn có workload cần bộ xử lý GPU, node Windows hoặc VM cô lập.
• Xác nhận các node: Xem Thiết lập node hợp lệ để biết thông tin về cách đảm bảo một node đáp ứng các yêu cầu để tham gia cụm Kubernetes.
• Thêm các node vào cụm: Nếu bạn đang quản lý cụm của riêng mình, bạn có thể thêm các node bằng cách thiết lập các máy của riêng bạn và thêm chúng theo cách thủ công hoặc để chúng tự đăng ký với apiserver của cụm. Xem phần Nodes để biết thông tin về cách thiết lập Kubernetes để thêm các nút theo những cách này.
• Quy mô các node: Sau cùng bạn sẽ cần có một kế hoạch để mở rộng khả năng của cụm. Xem Các cân nhắc cho những cụm lớn để giúp xác định bạn cần bao nhiêu node, dựa trên số lượng pod và container bạn cần chạy. Nếu bạn đang tự quản lý các node, điều này có thể có nghĩa là mua và cài đặt thiết bị vật lý của riêng bạn.
• Autoscale các node: Đọc Node Autoscaling để tìm hiểu về các công cụ có sẵn để tự động quản lý các node của bạn và khả năng chúng cung cấp.
• Thiết lập kiểm tra sức khỏe node: Đối với những workload quan trọng, bạn muốn đảm bảo rằng các node và các pod chạy trên các node đó là khỏe mạnh. Sử dụng Trình phát hiện vấn đề node, bạn có thể đảm bảo các node của bạn khỏe mạnh.

Quản lý người dùng trên production

Trên production, bạn có thể chuyển từ một mô hình nơi bạn hoặc một nhóm nhỏ những người đang truy cập cụm đến nơi có khả năng có hàng tá hoặc hàng trăm người. Trong môi trường học tập hoặc nền tảng nguyên mẫu, bạn có thể có một tài khoản quản trị cho mọi thứ bạn làm. Trên production, bạn sẽ muốn nhiều tài khoản với các cấp độ truy cập khác nhau vào các namespace khác nhau.

Đảm nhận một cụm có chất lượng production nghĩa là quyết định việc bạn muốn làm thế nào để cho phép người dùng khác truy cập một cách chọn lọc. Đặc biệt, bạn cần chọn chiến lược để xác minh danh tính những người đang cố truy cập vào cụm của bạn (xác thực) và quyết định liệu họ có quyền làm những gì họ muốn (phân quyền):

• Xác thực: Apiserver có thể xác thực người dùng bằng chứng chỉ khác, bearer tokens, một proxy xác thực, hoặc HTTP basic auth. Bạn có thể chọn phương pháp xác thực bạn muốn. Băng việc sử dụng plugin, apiserver có thể tận dụng phương thức xác thực hiện có của tổ chức của bạn, ví dụ LDAP hoặc Kerberos. Xem Xác thực dể biết mô tả về các phương pháp xác thực người dùng Kubernetes khác nhau.
• Phân quyền: Khi bạn bắt đầu ủy quyền cho người dùng thường xuyên của mình, bạn có lẽ sẽ chọn giữa phân quyền RBAC và ABAC. Xem Tổng quan phân quyền để xem những chế độ phân quyền tài khoản người dùng khác nhau (cũng như quyền truy cập của service account tới cụm của bạn):
  • Kiểm soát truy cập dựa trên vai trò (RBAC): Cho phép bạn chỉ định quyền truy cập vào cụm bằng cách cho phép thiết lập một tập các quyền tới người dùng đã xác thực. Quyền có thể được chỉ định trong một namespace cụ thể (Role) hoặc trong cả cụm (ClusterRole). Sau đó sử dụng RoleBindings và ClusterRoleBindings, những quyền này có thể được gán tới những người dùng cụ thể.
  • Kiểm soát truy cập dựa trên thuộc tính (ABAC): Cho phép bạn tạo các chính sách dựa trên thuộc tính của tài nguyên trong cụm và sẽ cho phép hoặc hoặc từ chối truy cập dựa trên những thuộc tính đó. Mỗi dòng trong 1 file chính sách xác định phiên bản của thuộc tính (apiVersion and kind) và một ánh xạ các thuộc tính đặc trưng để gán tới một chủ thể (người dùng hoặc nhóm), thuộc tính tài nguyên, thuộc tính phi tài nguyên (/versions hoặc /apis), và chỉ đọc. Xem Các ví dụ để biết thêm chi tiết

Với tư cách là người thiết lập xác thực và phân quyền trên cụm Kubernetes production, dưới đây là một số điều cần cân nhắc:

• Đặt chế độ phân quyền: Khi Kubernetes API server (kube-apiserver) khởi động, chế độ hỗ trợ phân quyền phải được thiết lập bằng cờ --authorization-config file hoặc --authorization-mode. Ví dụ, cờ đó trong kube-adminserver.yaml file (tại /etc/kubernetes/manifests) có thể được đặt là Node,RBAC. Điều này sẽ cho phép phân quyền Node và RBAC tới những yêu cầu đã xác thực.
• Tạo chứng chỉ người dùng và role bindings (RBAC): Nếu bạn sử dụng phân quyền RBAC, người dùng có thể tạo một CertificateSigningRequest (CSR) và sẽ được ký bởi CA của cụm. Sau đó bạn có thể gán Roles và ClusterRoles tới từng người dùng. Xem Certificate Signing Requests để biết thêm chi tiết.
• Tạo các chính sách kết hợp các thuộc tính (ABAC): Nếu bạn sử dụng phân quyền ABAC, bạn có thể gán sự kết hợp các thuộc tính thành các chính sách để phân quyền tới người dùng hoặc nhóm được chọn để họ có thể truy cập tới những tài nguyên cụ thể (ví dụ pod), namespace, hoặc apiGroup. Để biết thêm thông tin, xem Các ví dụ.
• Cân nhắc Admission Controllers: Các hình thức phân quyền bổ sung cho các yêu cầu đến thông qua API server bao gồm Webhook Token Authentication. Webhooks và những loại phân quyền đặc biệt khác cần được kích hoạt bằng cách thêm Admission Controllers vào API server.

Đặt giới hạn tài nguyên cho workload

Những yêu cầu từ production workload có thể gây ra áp lực lên cả trong và ngoài Kubernetes control plane. Hãy cân nhắc những mục này khi thiết lập cho nhu cầu của workload trong cụm của bạn:

• Đặt giới hạn namespace: Đặt từng namespace quotas lên những thứ như bộ nhớ và CPU. Xem Quản lý Bộ nhớ, CPU, và API Resources để biết thêm chi tiết.
• Chuẩn bị cho yêu cầu DNS: Nếu bạn mong đợi workloads mở rộng một cách ồ ạt, dịch vụ DNS của bạn phải săn sàng để mở rộng quy mô. Xem Autoscale dịch vụ DNS trong cụm.
• Tạo thêm các service account: Tài khoản người dùng (user account) xác định những gì người dùng có thể thực hiện trên một cụm, trong khi đó một tài khoản dịch vụ (service account) định nghĩa khả năng truy cập của pod trong một namespace cụ thể. Mặc định, một pod sẽ tiếp nhận service account default từ namespace của nó. Xem Quản lý Service Account để biết cách tạo một service account. Ví dụ, bạn có thể muốn:
  • Thêm secret cho pod để có thể pull image từ một container registry cụ thể. Xem Cấu hình Service Account cho Pods.
  • Gán các quyền RBAC tới một service account. Xem các quyền ServiceAccount để biết thêm chi tiết.

Tiếp theo là gì

• Quyết định liệu bạn muốn tự dựng cụm Kubernetes production hay đạt được từ những nhà cung cấp Turnkey Cloud Solutions hoặc các đối tác Kubernetes Partners.
• Nếu bạn chọn dựng cụm cho riêng bạn, lập kế hoạch về việc xử lý các chứng chỉ và thiết lập tính sẵn sàng cao cho các thành phần, ví dụ etcd và API server.
• Chọn phương pháp triển khai bằng kubeadm, kops hay Kubespray.
• Cấu hình quản lý người dùng bằng cách xác định các phương pháp Xác thực và Phân quyền.
• Chuẩn bị cho workload ứng dụng bằng cách thiết lập giới hạn tài nguyên, DNS autoscaling và các service account.

2.1.1 - Cài đặt Kubernetes với các công cụ triển khai

Có nhiều phương pháp và công cụ cho việc cài đặt cụm Kubernetes production của bạn. Ví dụ:

• kubeadm

• Cluster API: Một dự án con Kubernetes tập trung vào việc cung cấp API và công cụ khai báo để đơn giản hóa việc cung cấp, nâng cấp và vận hành nhiều cụm Kubernetes.

• kops: Một công cụ cung cấp cụm tự động. Đối với các hướng dẫn, thực hành tốt nhất, tùy chọn cấu hình và thông tin về tiếp cận với cộng đồng, vui lòng kiểm tra kOps website để biết chi tiết.

• kubespray: Một sự phối hợp của Ansible playbooks, inventory, các công cụ cung cấp, và kiến ​​thức chuyên môn cho các tác vụ quản lý cấu hình Hệ điều hành/cụm Kubernetes chung. Bạn có thể tiếp cận tới cộng đồng trên kênh Slack #kubespray.

2.1.1.1 - Khởi tạo cụm với kubeadm

2.1.1.1.1 - Cài đặt kubeadm

Trang này hướng dẫn cách cài đặt hộp công cụ kubeadm. Để biết thông tin về cách tạo một cụm với Kubeadm sau khi bạn đã thực hiện quy trình cài đặt này, xem trang Tạo một cụm với kubeadm.

Trước khi bạn bắt đầu

• Một máy chủ Linux tương thích. Dự án Kubernetes cung cấp những hướng dẫn chung cho các bản phân phối Linux dựa trên Debian và Red Hat, và những bản phân phối không có trình quản lý gói.
• 2 GB RAM hoặc nhiều hơn cho mỗi máy (nếu ít hơn sẽ không đủ tài nguyên cho các ứng dụng của bạn).
• 2 CPU hoặc nhiều hơn cho các máy control plane.
• Kết nối toàn mạng giữa tất cả các máy trong cụm (mạng public hoặc private đều được).
• Mọi máy phải có hostname, địa chỉ MAC, và product_uuid duy nhất. Xem tại đây để biết thêm chi tiết.
• Một số cổng được mở trên máy của bạn. Xem tại đây để biết thêm chi tiết.

Kiểm tra phiên bản OS

• Linux
• Windows

Một cụm Kubernetes được tạo bởi kubeadm phụ thuộc vào phần mềm mà chúng sử dụng các chức năng kernel. Phần mềm này bao gồm, nhưng không giới hạn ở container runtime, kubelet, và một plugin Container Network Interface.

Để giúp bạn tránh những lỗi không mong muốn khi sử dụng một phiên bản kernel không được hỗ trợ, kubeadm chạy kiểm tra pre-flight SystemVerification. Quá trình kiểm tra này sẽ lỗi nếu phiên bản kernel không được hỗ trợ.

Bạn có thể chọn bỏ qua kiểm tra, nếu bạn biết rằng kernel của bạn cung cấp các chức năng cần thiết, kể cả kubeadm không hỗ trợ phiên bản đó.

Xác nhận địa chỉ MAC và product_uuid là duy nhất cho từng node

• Bạn có thể biết được địa chỉ MAC của network interfaces bằng câu lệnh ip link hoặc ifconfig -a
• product_uuid có thể kiểm tra bằng câu lệnh sudo cat /sys/class/dmi/id/product_uuid

Rất có thể các thiết bị phần cứng sẽ có các địa chỉ duy nhất, mặc dù một vài máy ảo có thể có các giá trị giống hệt nhau. Kubernetes sử dụng những giá trị đó để định danh duy nhất cho các node trong cụm. Nếu các giá trị đó không là duy nhất cho từng node, quá trình cái đặt có thể thất bại.

Kiểm tra network adapter

Nếu bạn có nhiều hơn một network adapter, và các thành phần Kubernetes của bạn không thể truy cập trên route mặc định, chúng tôi khuyên bạn nên bổ sung (các) IP route để các địa chỉ cụm Kubernetes đi qua adpater thích hợp.

Kiểm tra các cổng cần thiết

Những cổng cần thiết cần phải được mở để các thành phần Kubernetes giao tiếp với nhau. Bạn có thể sử dụng công cụ như netcat để kiểm tra cổng có được mở hay không. Ví dụ:

nc 127.0.0.1 6443 -zv -w 2

Pod network plugin mà bạn sử dụng cũng có thể yêu cầu mở một số cổng nhất định. Vì điều này khác nhau đối với từng pod network plugin, vui lòng xem tài liệu của các plugin về (các) cổng cần thiết.

Cấu hình swap

Mặc định kubelet sẽ không thể khởi động nếu bộ nhớ swap được phát hiện trên một node. Điều này có nghĩa rằng swap nên hoặc là tắt đi hoặc là được chấp nhận bởi kubelet.

• Để chấp nhận swap, thêm failSwapOn: false vào cấu hình kubelet hoặc thông qua tham số dòng lệnh. Lưu ý: thậm chí nếu failSwapOn: false được thêm, workload mặc định cũng không có quyền truy cập swap. Điều này có thể được thay đổi bằng cách đặt swapBehavior, một lần nữa trong file cấu hình kubelet. Để sử dụng swap, đặt một swapBehavior khác với giá trị mặc định NoSwap. Xem Quản lý bộ nhớ swap để biết thêm chi tiết.
• Để tắt swap, sudo swapoff -a có thể được sử dụng để tắt tạm thời. Để làm cho thay đổi này duy trì mỗi khi tái khởi động, đảm bảo rằng swap được tắt trong các file cấu hình như /etc/fstab, systemd.swap, phụ thuộc vào việc nó được cấu hình như thế nào trên hệ thống của bạn.

Cài đặt một container runtime

Để chạy các container trong các Pod, Kubernetes sử dụng một container runtime.

Mặc định, Kubernetes sử dụng Container Runtime Interface (CRI) để giao tiếp với container runtime mà bạn chọn.

Nếu bạn không chỉ định một runtime, kubeadm tự động phát hiện một container runtime đã cài đặt bằng cách quét qua một danh sách những endpoint đã biết.

Nếu có nhiều hoặc không có container runtime nào được phát hiện, kubeadm sẽ ném ra một lỗi và sẽ yêu cầu bạn chỉ định một thứ bạn muốn sử dụng.

Xem container runtimes để biết thêm thông tin.

Những bản bên dưới bao gồm những endpoint đã biết của những hệ điều hành được hỗ trợ:

• Linux
• Windows

Cài đặt kubeadm, kubelet và kubectl

Bạn sẽ cài đặt các package này trên toàn bộ máy chủ của bạn:

• kubeadm: lệnh khởi tạo cụm.

• kubelet: thành phần chạy trên toàn bộ các máy trong cụm của bạn và làm những việc như khởi chạy pod và container.

• kubectl: tiện ích dòng lệnh để giao tiếp với cụm.

kubeadm sẽ không cài đặt hoặc quản lý kubelet và kubectl cho bạn, vì vậy bạn sẽ cần phải đảm bảo rằng phiên bản của chúng giống với Kubernetes control plane bạn muốn kubeadm cài cho bạn. Nếu bạn không làm vậu, rủi ro về sự chênh lệch phiên bản có thể xảy ra và dẫn tới những hành vi lỗi, không mong muốn. Tuy nhiên, chênh lệch một phiên bản minor giữa kubelet và control plane được chấp nhận, nhưng phiên bản kubelet không bao giờ vượt quá phiên bản API server. Ví dụ, kubelet đang chạy 1.7.0 có thể tương thích hoàn toàn với API server phiên bản 1.8.0, nhưng không có chiều ngược lại.

Để biết cách cài đặt kubectl, xem Cài đặt và thiết lập kubectl.

Để biết thêm thông tin về chênh lệch phiên bản, xem:

• Chính sách về phiên bản và chênh lệch phiên bản của Kubernetes
• Chính sách sai lệch phiên bản cụ thể cho kubeadm

• Các bản phân phối dựa trên Debian
• Các bản phân phối dựa trên Red Hat
• Không dùng trình quản lý package

CNI_PLUGINS_VERSION="v1.3.0"
ARCH="amd64"
DEST="/opt/cni/bin"
sudo mkdir -p "$DEST"
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_PLUGINS_VERSION}/cni-plugins-linux-${ARCH}-${CNI_PLUGINS_VERSION}.tgz" | sudo tar -C "$DEST" -xz

DOWNLOAD_DIR="/usr/local/bin"
sudo mkdir -p "$DOWNLOAD_DIR"

CRICTL_VERSION="v1.31.0"
ARCH="amd64"
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz

RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
ARCH="amd64"
cd $DOWNLOAD_DIR
sudo curl -L --remote-name-all https://dl.k8s.io/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet}
sudo chmod +x {kubeadm,kubelet}

RELEASE_VERSION="v0.16.2"
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/krel/templates/latest/kubelet/kubelet.service" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /usr/lib/systemd/system/kubelet.service
sudo mkdir -p /usr/lib/systemd/system/kubelet.service.d
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/krel/templates/latest/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf

sudo systemctl enable --now kubelet

Bây giờ kubelet khởi động sau mỗi vài giây, vì nó đợi trong vòng lặp crashloop chờ kubeadm bảo nó phải làm gì.

Cấu hình cgroup driver

Cả container runtime và kubelet có một thuộc tính gọi là "cgroup driver", cái mà quan trọng cho việc quản lý các cgroup trên các máy Linux.

Khắc phục sự cố

Nếu bạn đang gặp các khó khăn với kubeadm, vui lòng tham khảo tài liệu khắc phục sự cố của chúng tôi.

Tiếp theo là gì

• Sử dụng kubeadm để Tạo một cụm

2.1.1.1.2 - Thiết lập một cụm etcd có tính Sẵn sàng cao (High Availability) với kubeadm

Mặc định, kubeadm chạy một instance etcd cục bộ trên từng node control plane. Bạn cũng có thể thiết lập cụm etcd bên ngoài và cung cấp các etcd instance trên các máy chủ riêng biệt. Những sự khác biệt giữa hai cách tiếp cận này được trình bày trong trang Các tùy chọn cho kiến trúc có tính Sẵn sàng cao.

Tác vụ này hướng dẫn quy trình tạo một cụm etcd bên ngoài có tính sẵn sàng cao gồm ba member mà kubeadm có thể sử dụng trong quá trình tạo cụm.

Trước khi bạn bắt đầu

• Ba máy chủ có thể giao tiếp với nhau qua cổng TCP 2379 và 2380. Tài liệu này giả định các cổng mặc định này. Tuy nhiên, chúng có thể được cấu hình thông qua tệp cấu hình kubeadm.
• Mỗi máy chủ phải có systemd và đã cài đặt một shell tương thích với bash.
• Mỗi máy chủ phải đã cài đặt một container runtime, kubelet, và kubeadm.
• Mỗi máy chủ phải có quyền truy cập vào Kubernetes container image registry (registry.k8s.io) hoặc list/pull image etcd cần thiết bằng lệnh kubeadm config images list/pull. Hướng dẫn này sẽ cài đặt các etcd instance dạng static pods được quản lý bởi kubelet.
• Một số công cụ để sao chép các file giữa các máy chủ. Ví dụ ssh và scp có thể đáp ứng yêu cầu này.

Thiết lập cụm

Cách tiếp cận thông thường là tạo ra toàn bộ chứng chỉ trên một node và chỉ phân bổ những file quan trọng tới các node khác.

1. Cấu hình kubelet để trở thành trình quản lý dịch vụ cho etcd.

   Lưu ý:

   Bạn phải thực hiện điều này trên toàn bộ các máy chủ chạy etcd.
   Vì etcd sẽ được tạo ra trước tiên, bạn phải ghi đè độ ưu tiên dịch vụ bằng cách tạo ra một unit file mới có độ ưu tiên cao hơn kubelet unit file mà kubeadm cung cấp.

   cat << EOF > /etc/systemd/system/kubelet.service.d/kubelet.conf
   # Thay thế "systemd" bằng giá trị cgroup driver của container runtime của bạn. Giá trị mặc định trong kubelet là "cgroupfs".
   # Thay thế giá trị của "containerRuntimeEndpoint" bằng một container runtime khác nếu cần.
   #
   apiVersion: kubelet.config.k8s.io/v1beta1
   kind: KubeletConfiguration
   authentication:
     anonymous:
       enabled: false
     webhook:
       enabled: false
   authorization:
     mode: AlwaysAllow
   cgroupDriver: systemd
   address: 127.0.0.1
   containerRuntimeEndpoint: unix:///var/run/containerd/containerd.sock
   staticPodPath: /etc/kubernetes/manifests
   EOF
   
   cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf
   [Service]
   ExecStart=
   ExecStart=/usr/bin/kubelet --config=/etc/systemd/system/kubelet.service.d/kubelet.conf
   Restart=always
   EOF
   
   systemctl daemon-reload
   systemctl restart kubelet
   

   Kiểm tra trạng thái kubelet để chắc chắn rằng nó đang chạy.

   systemctl status kubelet
   

2. Tạo các file cấu hình cho kubeadm.

   Tạo một file cấu hình kubeadm cho từng máy chủ mà có etcd member chạy trên đó sử dụng tập lệnh dưới đây.

   # Thay đổi HOST0, HOST1 và HOST2 với các IP của các máy của bạn
   export HOST0=10.0.0.6
   export HOST1=10.0.0.7
   export HOST2=10.0.0.8
   
   # Thay đổi NAME0, NAME1 và NAME2 bằng hostnames của các máy của bạn
   export NAME0="infra0"
   export NAME1="infra1"
   export NAME2="infra2"
   
   # Tạo các thư mục tạm thời để lưu các file sẽ xuất hỉện trên các máy khác
   mkdir -p /tmp/${HOST0}/ /tmp/${HOST1}/ /tmp/${HOST2}/
   
   HOSTS=(${HOST0} ${HOST1} ${HOST2})
   NAMES=(${NAME0} ${NAME1} ${NAME2})
   
   for i in "${!HOSTS[@]}"; do
   HOST=${HOSTS[$i]}
   NAME=${NAMES[$i]}
   cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml
   ---
   apiVersion: "kubeadm.k8s.io/v1beta4"
   kind: InitConfiguration
   nodeRegistration:
       name: ${NAME}
   localAPIEndpoint:
       advertiseAddress: ${HOST}
   ---
   apiVersion: "kubeadm.k8s.io/v1beta4"
   kind: ClusterConfiguration
   etcd:
       local:
           serverCertSANs:
           - "${HOST}"
           peerCertSANs:
           - "${HOST}"
           extraArgs:
           - name: initial-cluster
             value: ${NAMES[0]}=https://${HOSTS[0]}:2380,${NAMES[1]}=https://${HOSTS[1]}:2380,${NAMES[2]}=https://${HOSTS[2]}:2380
           - name: initial-cluster-state
             value: new
           - name: name
             value: ${NAME}
           - name: listen-peer-urls
             value: https://${HOST}:2380
           - name: listen-client-urls
             value: https://${HOST}:2379
           - name: advertise-client-urls
             value: https://${HOST}:2379
           - name: initial-advertise-peer-urls
             value: https://${HOST}:2380
   EOF
   done
   

3. Tạo cơ quan cấp chứng chỉ (CA).

   Nếu bạn đã có một CA, việc tiếp theo chỉ cần sao chép các file crt và key của CA tới /etc/kubernetes/pki/etcd/ca.crt và /etc/kubernetes/pki/etcd/ca.key. Sau khi các file đó được sao chép, tiến hành các bước tiếp theo, "Tạo các chứng chỉ cho từng member member".

   Nếu bạn chưa có CA nào, hãy chạy câu lệnh này trên $HOST0 (nơi bạn tạo các file cấu hình cho kubeadm).

   kubeadm init phase certs etcd-ca
   

   Nó sẽ tạo ra hai file:

   • /etc/kubernetes/pki/etcd/ca.crt
   • /etc/kubernetes/pki/etcd/ca.key

4. Tạo các chứng chỉ cho từng member member.

   kubeadm init phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
   kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
   cp -R /etc/kubernetes/pki /tmp/${HOST2}/
   # Dọn dẹp các chứng chỉ không sử dụng
   find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
   
   kubeadm init phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
   kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
   cp -R /etc/kubernetes/pki /tmp/${HOST1}/
   find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
   
   kubeadm init phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml
   kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
   kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
   # Không cần phải di chuyển các chứng chỉ vì chúng dành cho HOST0
   
   # Dọn dẹp các chứng chỉ không nên sao chép khỏi máy chủ này
   find /tmp/${HOST2} -name ca.key -type f -delete
   find /tmp/${HOST1} -name ca.key -type f -delete
   

5. Sao chép các chứng chỉ và các cấu hình kubeadm.

   Các chứng chỉ này đã được tạo ra và bây giờ chúng cần được đưa tới từng máy chủ tương ứng.

   USER=ubuntu
   HOST=${HOST1}
   scp -r /tmp/${HOST}/* ${USER}@${HOST}:
   ssh ${USER}@${HOST}
   USER@HOST $ sudo -Es
   root@HOST $ chown -R root:root pki
   root@HOST $ mv pki /etc/kubernetes/
   

6. Đảm bảo đã có đủ toàn bộ các file cần thiết.

   Danh sách đầy đủ các file cần thiết trên $HOST0 gồm:

   /tmp/${HOST0}
   └── kubeadmcfg.yaml
   ---
   /etc/kubernetes/pki
   ├── apiserver-etcd-client.crt
   ├── apiserver-etcd-client.keyt
   └── etcd
       ├── ca.crt
       ├── ca.key
       ├── healthcheck-client.crt
       ├── healthcheck-client.key
       ├── peer.crt
       ├── peer.key
       ├── server.crt
       └── server.key
   

   Trên $HOST1:

   $HOME
   └── kubeadmcfg.yaml
   ---
   /etc/kubernetes/pki
   ├── apiserver-etcd-client.crt
   ├── apiserver-etcd-client.key
   └── etcd
       ├── ca.crt
       ├── healthcheck-client.crt
       ├── healthcheck-client.key
       ├── peer.crt
       ├── peer.key
       ├── server.crt
       └── server.key
   

   Trên $HOST2:

   $HOME
   └── kubeadmcfg.yaml
   ---
   /etc/kubernetes/pki
   ├── apiserver-etcd-client.crt
   ├── apiserver-etcd-client.key
   └── etcd
       ├── ca.crt
       ├── healthcheck-client.crt
       ├── healthcheck-client.key
       ├── peer.crt
       ├── peer.key
       ├── server.crt
       └── server.key
   

7. Tạo các manifest cho static pod.

   Bây giờ các chứng chỉ và cấu hình đã có, đã đến lúc tạo các manifest. Trên mỗi máy chủ, hãy chạy lệnh kubeadm để tạo static manifest cho etcd.

   root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml
   root@HOST1 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml
   root@HOST2 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml
   

8. Tùy chọn: Kiểm tra sức khỏe cụm.

   Nếu etcdctl không có sẵn, bạn có thể chạy công cụ này trong một container image. Bạn sẽ thực hiện điều đó trực tiếp với container runtime của mình bằng cách sử dụng một công cụ như crictl run và không thông qua Kubernetes.

   ETCDCTL_API=3 etcdctl \
   --cert /etc/kubernetes/pki/etcd/peer.crt \
   --key /etc/kubernetes/pki/etcd/peer.key \
   --cacert /etc/kubernetes/pki/etcd/ca.crt \
   --endpoints https://${HOST0}:2379 endpoint health
   ...
   https://[HOST0 IP]:2379 is healthy: successfully committed proposal: took = 16.283339ms
   https://[HOST1 IP]:2379 is healthy: successfully committed proposal: took = 19.44402ms
   https://[HOST2 IP]:2379 is healthy: successfully committed proposal: took = 35.926451ms
   

   • Đặt ${HOST0} bằng địa chỉ IP của máy chủ bạn đang kiểm tra.

Tiếp theo là gì

Một khi bạn đã có một cụm etcd với 3 member đang chạy, bạn có thể tiếp tục thiết lập một control plane có tính sẵn sàng cao bằng phương pháp etcd bên ngoài với kubeadm.

2.2 - Một số cách thức cài đặt tốt

3 - Các khái niệm

Phần Khái niệm giúp bạn tìm hiểu về các bộ phận của hệ thống Kubernetes và các khái niệm mà Kubernetes sử dụng để biểu diễn cụm cluster của bạn, đồng thời giúp bạn hiểu sâu hơn về cách thức hoạt động của Kubernetes.

3.1 - Tổng quan

3.1.1 - Kubernetes là gì

Trang tổng quan của Kubernetes.

Kubernetes là một nền tảng nguồn mở, khả chuyển, có thể mở rộng để quản lý các ứng dụng được đóng gói và các service, giúp thuận lợi trong việc cấu hình và tự động hoá việc triển khai ứng dụng. Kubernetes là một hệ sinh thái lớn và phát triển nhanh chóng. Các dịch vụ, sự hỗ trợ và công cụ có sẵn rộng rãi.

Tên gọi Kubernetes có nguồn gốc từ tiếng Hy Lạp, có ý nghĩa là người lái tàu hoặc hoa tiêu. Google mở mã nguồn Kubernetes từ năm 2014. Kubernetes xây dựng dựa trên một thập kỷ rưỡi kinh nghiệm mà Google có được với việc vận hành một khối lượng lớn workload trong thực tế, kết hợp với các ý tưởng và thực tiễn tốt nhất từ cộng đồng.

Quay ngược thời gian

Chúng ta hãy xem tại sao Kubernetes rất hữu ích bằng cách quay ngược thời gian.

Thời đại triển khai theo cách truyền thống: Ban đầu, các ứng dụng được chạy trên các máy chủ vật lý. Không có cách nào để xác định ranh giới tài nguyên cho các ứng dụng trong máy chủ vật lý và điều này gây ra sự cố phân bổ tài nguyên. Ví dụ, nếu nhiều ứng dụng cùng chạy trên một máy chủ vật lý, có thể có những trường hợp một ứng dụng sẽ chiếm phần lớn tài nguyên hơn và kết quả là các ứng dụng khác sẽ hoạt động kém đi. Một giải pháp cho điều này sẽ là chạy từng ứng dụng trên một máy chủ vật lý khác nhau. Nhưng giải pháp này không tối ưu vì tài nguyên không được sử dụng đúng mức và rất tốn kém cho các tổ chức để có thể duy trì nhiều máy chủ vật lý như vậy.

Thời đại triển khai ảo hóa: Như một giải pháp, ảo hóa đã được giới thiệu. Nó cho phép bạn chạy nhiều Máy ảo (VM) trên CPU của một máy chủ vật lý. Ảo hóa cho phép các ứng dụng được cô lập giữa các VM và cung cấp mức độ bảo mật vì thông tin của một ứng dụng không thể được truy cập tự do bởi một ứng dụng khác.

Ảo hóa cho phép sử dụng tốt hơn các tài nguyên trong một máy chủ vật lý và cho phép khả năng mở rộng tốt hơn vì một ứng dụng có thể được thêm hoặc cập nhật dễ dàng, giảm chi phí phần cứng và hơn thế nữa. Với ảo hóa, bạn có thể có một tập hợp các tài nguyên vật lý dưới dạng một cụm các máy ảo sẵn dùng.

Mỗi VM là một máy tính chạy tất cả các thành phần, bao gồm cả hệ điều hành riêng của nó, bên trên phần cứng được ảo hóa.

Thời đại triển khai Container: Các container tương tự như VM, nhưng chúng có tính cô lập để chia sẻ Hệ điều hành (HĐH) giữa các ứng dụng. Do đó, container được coi là nhẹ (lightweight). Tương tự như VM, một container có hệ thống tệp (filesystem), CPU, bộ nhớ, process space, v.v. Khi chúng được tách rời khỏi cơ sở hạ tầng bên dưới, chúng có thể khả chuyển (portable) trên cloud hoặc các bản phân phối Hệ điều hành.

Các container đã trở nên phổ biến vì chúng có thêm nhiều lợi ích, chẳng hạn như:

• Tạo mới và triển khai ứng dụng Agile: gia tăng tính dễ dàng và hiệu quả của việc tạo các container image so với việc sử dụng VM image.
• Phát triển, tích hợp và triển khai liên tục: cung cấp khả năng build và triển khai container image thường xuyên và đáng tin cậy với việc rollbacks dễ dàng, nhanh chóng.
• Phân biệt giữa Dev và Ops: tạo các images của các application container tại thời điểm build/release thay vì thời gian triển khai, do đó phân tách các ứng dụng khỏi hạ tầng.
• Khả năng quan sát không chỉ hiển thị thông tin và các metric ở mức Hệ điều hành, mà còn cả application health và các tín hiệu khác.
• Tính nhất quán về môi trường trong suốt quá trình phát triển, testing và trong production: Chạy tương tự trên laptop như trên cloud.
• Tính khả chuyển trên cloud và các bản phân phối HĐH: Chạy trên Ubuntu, RHEL, CoreOS, on-premises, Google Kubernetes Engine và bất kì nơi nào khác.
• Quản lý tập trung ứng dụng: Tăng mức độ trừu tượng từ việc chạy một Hệ điều hành trên phần cứng ảo hóa sang chạy một ứng dụng trên một HĐH bằng logical resources.
• Các micro-services phân tán, elastic: ứng dụng được phân tách thành các phần nhỏ hơn, độc lập và thể được triển khai và quản lý một cách linh hoạt - chứ không phải một app nguyên khối (monolithic).
• Cô lập các tài nguyên: dự đoán hiệu năng ứng dụng
• Sử dụng tài nguyên: hiệu quả

Tại sao bạn cần Kubernetes và nó có thể làm những gì?

Các container là một cách tốt để đóng gói và chạy các ứng dụng của bạn. Trong môi trường production, bạn cần quản lý các container chạy các ứng dụng và đảm bảo rằng không có khoảng thời gian downtime. Ví dụ, nếu một container bị tắt đi, một container khác cần phải khởi động lên. Điều này sẽ dễ dàng hơn nếu được xử lý bởi một hệ thống.

Đó là cách Kubernetes đến với chúng ta. 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ẽ. Nó đảm nhiệm việc nhân rộng và chuyển đổi dự phòng cho ứng dụng của bạn, cung cấp các mẫu deployment và hơn thế nữa. Ví dụ, Kubernetes có thể dễ dàng quản lý một triển khai canary cho hệ thống của bạn.

Kubernetes cung cấp cho bạn:

• Service discovery và cân bằng tải
  Kubernetes có thể expose một container sử dụng DNS hoặc địa chỉ IP của riêng nó. Nếu lượng traffic truy cập đến một container cao, Kubernetes có thể cân bằng tải và phân phối lưu lượng mạng (network traffic) để việc triển khai được ổn định.
• Điều phối bộ nhớ
  Kubernetes cho phép bạn tự động mount một hệ thống lưu trữ mà bạn chọn, như local storages, public cloud providers, v.v.
• Tự động rollouts và rollbacks
  Bạn có thể mô tả trạng thái mong muốn cho các container được triển khai dùng Kubernetes và nó có thể thay đổi trạng thái thực tế sang trạng thái mong muốn với tần suất được kiểm soát. Ví dụ, bạn có thể tự động hoá Kubernetes để tạo mới các container cho việc triển khai của bạn, xoá các container hiện có và áp dụng tất cả các resource của chúng vào container mới.
• Đóng gói tự động
  Bạn cung cấp cho Kubernetes một cluster gồm các node mà nó có thể sử dụng để chạy các tác vụ được đóng gói (containerized task). Bạn cho Kubernetes biết mỗi container cần bao nhiêu CPU và bộ nhớ (RAM). Kubernetes có thể điều phối các container đến các node để tận dụng tốt nhất các resource của bạn.
• Tự phục hồi
  Kubernetes khởi động lại các containers bị lỗi, thay thế các container, xoá các container không phản hồi lại cấu hình health check do người dùng xác định và không cho các client biết đến chúng cho đến khi chúng sẵn sàng hoạt động.
• Quản lý cấu hình và bảo mật
  Kubernetes cho phép bạn lưu trữ và quản lý các thông tin nhạy cảm như: password, OAuth token và SSH key. Bạn có thể triển khai và cập nhật lại secret và cấu hình ứng dụng mà không cần build lại các container image và không để lộ secret trong cấu hình stack của bạn.

Kubernetes không phải là gì?

Kubernetes không phải là một hệ thống PaaS (Nền tảng như một Dịch vụ) truyền thống, toàn diện. Do Kubernetes hoạt động ở tầng container chứ không phải ở tầng phần cứng, nó cung cấp một số tính năng thường áp dụng chung cho các dịch vụ PaaS, như triển khai, nhân rộng, cân bằng tải, ghi nhật ký và giám sát. Tuy nhiên, Kubernetes không phải là cấu trúc nguyên khối và các giải pháp mặc định này là tùy chọn và có thể cắm được (pluggable).

Kubernetes:

• Không giới hạn các loại ứng dụng được hỗ trợ. Kubernetes nhằm mục đích hỗ trợ một khối lượng công việc cực kỳ đa dạng, bao gồm cả stateless, stateful và xử lý dữ liệu. Nếu một ứng dụng có thể chạy trong một container, nó sẽ chạy rất tốt trên Kubernetes.
• Không triển khai mã nguồn và không build ứng dụng của bạn. Quy trình CI/CD được xác định bởi tổ chức cũng như các yêu cầu kỹ thuật.
• Không cung cấp các service ở mức ứng dụng, như middleware (ví dụ, các message buses), các framework xử lý dữ liệu (ví dụ, Spark), cơ sở dữ liệu (ví dụ, MySQL), bộ nhớ cache, cũng như hệ thống lưu trữ của cluster (ví dụ, Ceph). Các thành phần như vậy có thể chạy trên Kubernetes và/hoặc có thể được truy cập bởi các ứng dụng chạy trên Kubernetes thông qua các cơ chế di động, chẳng hạn như Open Service Broker.
• Không bắt buộc các giải pháp ghi lại nhật ký (logging), giám sát (monitoring) hoặc cảnh báo (alerting). Nó cung cấp một số sự tích hợp như proof-of-concept, và cơ chế để thu thập và xuất các số liệu.
• Không cung cấp, không bắt buộc một cấu hình ngôn ngữ/hệ thống (ví dụ: Jsonnet). Nó cung cấp một API khai báo có thể được targeted bởi các hình thức khai báo tùy ý.
• Không cung cấp cũng như áp dụng bất kỳ cấu hình toàn diện, bảo trì, quản lý hoặc hệ thống tự phục hồi.
• Ngoài ra, Kubernetes không phải là một hệ thống điều phối đơn thuần. Trong thực tế, nó loại bỏ sự cần thiết của việc điều phối. Định nghĩa kỹ thuật của điều phối là việc thực thi một quy trình công việc được xác định: đầu tiên làm việc A, sau đó là B rồi sau chót là C. Ngược lại, Kubernetes bao gồm một tập các quy trình kiểm soát độc lập, có thể kết hợp, liên tục điều khiển trạng thái hiện tại theo trạng thái mong muốn đã cho. Nó không phải là vấn đề làm thế nào bạn có thể đi được từ A đến C. Kiểm soát tập trung cũng không bắt buộc. Điều này dẫn đến một hệ thống dễ sử dụng hơn, mạnh mẽ hơn, linh hoạt hơn và có thể mở rộng.

Tiếp theo là gì

• Xem thêm về các thành phần của Kubernetes
• Sẵn sàng bắt đầu?

3.2 - Kiến Trúc Cluster

3.2.1 - Các khái niệm nền tảng của Cloud Controller Manager

Khái niệm Cloud Controller Manager (CCM) (để tránh nhầm lẫn với bản binary build cùng tên) được định nghĩa riêng biệt để cho phép các bên cung cấp dịch vụ cloud và thành phần chính của Kubernetes phát triển độc lập với nhau. CCM chạy đồng thời với những thành phần khác thuộc máy chủ của một cluster như Controller Manager của Kubernetes, API server, và Scheduler. Nó cũng có thể đóng vai trò như một addon cho Kubernetes.

Cloud Controller Manager này được thiết kế dựa trên cơ chế plugin nhằm cho phép các bên Cloud Provider có thể tích hợp với Kubernetes một cách dễ dàng thông qua các plugin này. Đã có những bản kế hoạch được thiết kế sẵn nhằm mục đích hỗ trợ những cloud provider thay đổi từ mô hình cũ sang mô hình mới đi chung với CCM.

Tài liệu này thảo luận về những khái niệm đằng sau một CCM và đưa ra những chi tiết về chức năng liên quan của nó.

Dưới đây là kiến trúc của một Kubernetes cluster khi không đi cùng với Cloud Controller Manager:

Thiết kế

Trong sơ đồ trên, Kubernetes và nhà cung cấp dịch vụ cloud được tích hợp thông qua một số thành phần sau:

• Kubelet
• Kubernetes Controller Manager
• Kubernetes API server

CCM hợp nhất tất cả các logic phụ thuộc trên một nền tàng Cloud từ 3 thành phần trên để tạo thành một điểm tích hợp duy nhất với hệ thống Cloud. Sơ đồ kiến trúc khi đi kèm với CCM sẽ trở thành:

Các thành phần của CCM

Cloud Controller Manager phân nhỏ một số chức năng của Kubernetes controller manager (KCM) và chạy nó như một tiến trình tách biệt. Cụ thể hơn, nó phân nhỏ những controller trong Kubernetes Controller Manager phụ thuộc vào Cloud. Kubernetes Controller Manager sẽ có những controller nhỏ hơn:

• Node controller
• Volume controller
• Route controller
• Service controller

Tại phiên bản 1.9, CCM thực hiện chạy những controller sau từ trong danh sách trên:

• Node controller
• Route controller
• Service controller

Kết hoạch ban đầu của dự án là hỗ trợ Volume sử dụng Cloud Controller Manager để áp dụng những Flex Volume linh hoạt nhằm dễ dàng tích hợp bổ sung thêm. Tuy nhiên, một giải pháp khác cũng đang được lên kế hoạch để thay thế Flex Volume được biết là CSI.

Sau khi xem xét về khía cạnh này, chúng tôi quyết định sẽ có một khoảng thời gian nghỉ trước khi CSI trở nên sẵn sàng cho việc sử dụng.

Chức năng của Cloud Controller Manager

CCM thừa hưởng những tính năng của nó từ các thành phần trong Kubernetes phụ thuộc vào các Cloud Provider. Phần kế tiếp sẽ giới thiệu những thành phần này.

1. Kubernetes Conntroller Manager

Phần lớn các tính năng của CCM bắt nguồn từ Kubernetes controller manager. Như đã đề cập ở phần trước, CCM bao gồm:

• Node controller
• Route controller
• Service controller

Node controller

Node controller có vai trò khởi tạo một Node bằng cách thu thập thông tin về những Node đang chạy trong cluster từ các cloud provider.

Node controller sẽ thực hiện những chức năng sau:

1. Khởi tạo một Node với các nhãn region/zone.
2. Khởi tạo một Node với những thông tin được cung cấp từ cloud, ví dụ như loại máy và kích cỡ.
3. Thu thập địa chỉ mạng của Node và hostname.
4. Trong trường hợp một Node không có tín hiệu phản hồi, Node controller sẽ kiểm tra xem Node này có thực sự xóa khỏi hệ thống cloud hay chưa. Nếu Node đó không còn tồn tại trên cloud, controller sẽ xóa Node đó khỏi Kubernetes cluster.

Route controller

Route controller đóng vai trò cấu hình định tuyến trong nằm trong hệ thống cloud để các container trên các Node khác nhau trong Kubernetes cluster có thể giao tiếp với nhau. Route controller hiện chỉ đáp ứng được cho các Google Compute Engine cluster.

Service controller

Service controller lắng nghe các sự kiện tạo mới, cập nhật và xoá bỏ một service. Dựa trên trạng thái hiện tại của các vụ trên Kubernetes, nó cấu hình các dịch vụ cân bằng tải trên cloud (như ELB của AWS, Google Load Balancer, hay Oracle Cloud Infrastructure LB) nhằm phản ánh trạng thái của các Service trên Kubernetes. Ngoài ra, nó đảm bảo những service backends cho các dịch vụ cần bằng tải trên cloud được cập nhật

2. Kubelet

Node controller bao gồm một số tính năng phụ thuộc vào tầng cloud của Kubelet. Trước khi có CCM, Kubelet đảm nhận vai trò khởi tạo một Node với thông tin chi tiết từ cloud như địa chỉ IP, region hay instance type. Với CCM, vai trò này được CCM đảm nhận thay cho Kubelet.

Với mô hình mới này, Kubelet sẽ khởi tạo một Node nhưng không đi kèm với những thông tin từ cloud. Tuy nhiên, nó sẽ thêm vào một dấu Taint để đánh dấu Node sẽ không được lập lịch cho tới khi CCM khởi tạo xong Node này với những thông tin cụ thể cung cấp từ Cloud, sau đó nó sẽ xóa những dấu chờ này.

Cơ chế Plugin

CCM sử dụng interface trong ngôn ngữ Go cho phép triển khai trên bất kì hệ thống cloud nào cũng có thể plugged in. Cụ thể hơn, nó sử dụng CloudProvider Interface được định nghĩa ở đây.

Cách triển khai của bốn controller được nêu ở trên, và một số được thực hiện như giao diện chung cho các bên cung cấp dịch vụ cloud, sẽ ở trong lõi (core) của Kubernetes. Việc triển khai dành riêng cho từng cloud provider sẽ được xây dựng bên ngoài lõi (core) và triển khai các giao diện được xác định bên trong lõi.

Để biết thêm chỉ tiết, xem Cloud Controller Manager.

Phân quyền

Phần này sẽ phân nhỏ quyền truy cập cần có cho các API object cung cấp bởi CCM để thực hiện những hành động của nó.

Node controller

Node controller chỉ hoạt động với các Node. Nó yêu cầu đầy đủ quyền truy cập bao gồm get, list, create, update, patch, watch, và delete một Node.

v1/Node:

• Get
• List
• Create
• Update
• Patch
• Watch
• Delete

Route controller

Route controller lắng nghe sự kiện tạo ra các Node và cấu hình các Route tương ứng. Nó yêu cầu có quyền truy cập get tới các đối Node.

v1/Node:

• Get

Service controller

Service controller lắng nghe các sự kiện khởi tạo, cập nhật và xóa bỏ một Service và cấu hình những endpoint phù hợp.

Để truy cập các Service, nó cần quyền list, và watch. Để cập nhật Service, nó sẽ cần patch và update.

Để thiết lập các endpoint cho các Service, nó cần quyền create, list, get, watch, và update.

v1/Service:

• List
• Get
• Watch
• Patch
• Update

Các vấn đề khác

Việc triển khai lõi của CCM yêu cầu cần có quyền tạo mới sự kiện và đảm bảo quyền thực thi một số hành động, nó cần có quyền tạo các Service Accounts

v1/Event:

• Create
• Patch
• Update

v1/ServiceAccount:

• Create

Với RBAC ClusterRole, CCM cần có ClusterRole tối thiểu:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cloud-controller-manager
rules:
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create
      - patch
      - update
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - "*"
  - apiGroups:
      - ""
    resources:
      - nodes/status
    verbs:
      - patch
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - list
      - patch
      - update
      - watch
  - apiGroups:
      - ""
    resources:
      - serviceaccounts
    verbs:
      - create
  - apiGroups:
      - ""
    resources:
      - persistentvolumes
    verbs:
      - get
      - list
      - update
      - watch
  - apiGroups:
      - ""
    resources:
      - endpoints
    verbs:
      - create
      - get
      - list
      - watch
      - update

Các nhà cung cấp đã triển khai

Sau đây là danh sách các nhà cung cấp dịch vụ cloud đã triển khai CCM:

• AWS
• Azure
• BaiduCloud
• DigitalOcean
• GCP
• Linode
• OpenStack
• Oracle
• TencentCloud

Quản lý Cluster

Hướng dẫn chi tiết cho việc cấu hình và chạy CCM được cung cấp tại đây.

3.3 - Containers

3.3.1 - Các biến môi trường của Container

Trang này mô tả các tài nguyên có sẵn cho các Containers trong môi trường Container.

Môi trường container

Môi trường Container trong Kubernetes cung cấp một số tài nguyên quan trọng cho Container:

• Một hệ thống tệp tin (filesystem), là sự kết hợp của một image và một hoặc nhiều volumes.
• Thông tin về chính container đó.
• Thông tin về các đối tượng (object) khác trong cluster.

Thông tin container

Hostname của một Container là tên của Pod mà Container đang chạy trong đó. Có thể lấy thông tin qua lệnh hostname hoặc lệnh gọi hàm gethostname trong libc.

Tên của Pod và namespace có thể lấy ở các biến môi trường thông qua downward API.

Các biến môi trường do người dùng định nghĩa từ định nghĩa của Pod cũng có trong thông tin của Container, như là mọi biến môi trường khác được xác định tĩnh trong Docker image.

Thông tin cluster

Một danh sách tất cả các services đang chạy khi một Container được tạo đều có trong Container dưới dạng các biến môi trường. Các biến môi trường này đều khớp với cú pháp của các Docker links.

Đối với một service có tên là foo ánh xạ với Container có tên là bar, các biến sau được xác định:

FOO_SERVICE_HOST=<host mà service đang chạy>
FOO_SERVICE_PORT=<port mà service đang chạy>

Các services có địa chỉ IP và có sẵn cho Container thông qua DNS nếu DNS addon được enable. 

Tiếp theo là gì

• Tìm hiểu thêm về Container lifecycle hooks.
• Trải nhiệm thực tế attaching handlers to Container lifecycle events.

3.3.2 - Container Lifecycle Hooks

Trang này mô tả cách mà kubelet quản lý các Container có thể sử dụng framework Container lifecycle hook để chạy mã nguồn được kích hoạt bởi các sự kiện trong lifecycle của nó.

Tổng quan

Tương tự như nhiều framework ngôn ngữ lập trình có thành phần các lifecycle hooks, như là Angular, Kubernetes cung cấp các Container cùng với các lifecycle hook. Các hooks cho phép các Container nhận thức được các sự kiện trong lifecycle của chúng và chạy mã nguồn được triển khai trong một trình xử lý khi lifecycle hook tương ứng được thực thi.

Container hooks

Có 2 hooks:

PostStart

Hook này thực thi ngay sau khi một container được tạo mới. Tuy nhiên, không có gì đảm bảo rằng hook này sẽ thực thi trước container ENTRYPOINT. Không có tham số nào được truyền cho trình xử lý (handler).

PreStop

Hook này được gọi ngay tức thì ngay trước khi một container bị chấm dứt bởi một API request hoặc quản lý sự kiện như liveness probe failure, preemption, tranh chấp tài nguyên và các vấn đề khác. Một lời gọi tới preStop hook thất bại nếu container đã ở trạng thái kết thúc hoặc đã hoàn thành. Nó đang chặn (blocking), có nghĩa là nó đồng bộ, vì vậy nó phải hoàn thành trước khi lời gọi xóa container có thể được gửi. Không có tham số nào được truyền cho trình xử lý (handler).

Xem thêm chi tiết về hành vi chấm dứt (termination behavior) tại Termination of Pods.

Các cách thực hiện Hook handler (Hook handler implementations)

Các container có thể truy cập một hook bằng cách thực hiện và đăng ký một handler cho hook đó. Có 2 loại hook handler có thể được triển khai cho các containers:

• Exec - Thực thi một lệnh cụ thể, như là pre-stop.sh trong cgroups và namespaces của Container. Tài nguyên được sử dụng bởi lệnh được tính vào Container.
• HTTP - Thực thi một HTTP request với một endpoint cụ thể trên Container.

Thực thi hook handler (Hook handler execution)

Khi một hook quản lý một Container lifecycle được gọi, hệ thống quản lý Kubernetes thực thi trình xử lý (handler) trong Container đã được đăng kí cho hook đó.

Các lời gọi hook handler là đồng bộ trong ngữ cảnh của Pod chứa Container. Điều này có nghĩa là đối với hook PostStart, Container ENTRYPOINT và hook thực thi/chạy không đồng bộ. Tuy nhiên, nếu hook mất quá nhiều thời gian để chạy hoặc treo, Container không thể đạt đến trạng thái running.

Behavior là tương tự cho một hook PreStop. Nếu hook bị treo trong khi thực thi, Pod phase ở trạng thái Terminating và bị xóa sau khoảng thời gian terminationGracePeriodSeconds của pod kết thúc. Nếu hook PostStart hoặc PreStop thất bại, nó sẽ xóa Container.

Người dùng nên làm cho hook handlers nhẹ nhất có thể. Tuy nhiên, có những trường hợp khi những lệnh chạy dài có ý nghĩa, chẳng hạn như khi lưu trạng thái trước khi dừng một container.

Hook delivery guarantees

Hook delivery được trù định ít nhất một lần, điều đó có nghĩa là hook có thể được gọi nhiều lần cho bất kỳ sự kiện cho trước nào, chẳng hạn như PostStart hoặc PreStop. Tùy thuộc vào việc thực hiện hook để xử lý việc này một cách chính xác.

Nhìn chung, chỉ có các deliveries đơn được thực hiện. Ví dụ, nếu một HTTP hook receiver bị down và không thể nhận các traffic, sẽ không được gửi lại. Tuy nhiên, trong một số trường hợp hiếm hoi, delivery kép có thể xảy ra. Chẳng hạn, nếu một kubelet khởi động lại ở giữa quá trình gửi một hook, hook có thể được gửi lại sau khi kubelet quay trở lại.

Debugging Hook handlers

Log cho một Hook handler không được hiển thị trong các Pod events. Nếu một handler thất bại vì lí do nào đó, nó sẽ broadcast một event. Đối với PostStart, đây là event FailedPostStartHook, và đối với PreStop, đây là event FailedPreStopHook. Bạn có thể xem những events này bằng cách chạy lệnh kubectl describe pod <pod_name>. Dưới đây là một số ví dụ output của events từ việc chạy lệnh này:

Events:
  FirstSeen  LastSeen  Count  From                                                   SubObjectPath          Type      Reason               Message
  ---------  --------  -----  ----                                                   -------------          --------  ------               -------
  1m         1m        1      {default-scheduler }                                                          Normal    Scheduled            Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
  1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Pulling              pulling image "test:1.0"
  1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Created              Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
  1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Pulled               Successfully pulled image "test:1.0"
  1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Started              Started container with docker id 5c6a256a2567
  38s        38s       1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Killing              Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
  37s        37s       1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Killing              Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
  38s        37s       2      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}                         Warning   FailedSync           Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
  1m         22s       2      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Warning   FailedPostStartHook

Tiếp theo là gì

• Xem thêm về Container environment.
• Kinh nghiệm thực hành gắn các trình xử lý vào các sự kiện trong lifecycle của Container.

4 - Tasks

Phần này của tài liệu chứa các hướng dẫn thực hiện các tác vụ. Mỗi tài liệu hướng dẫn tác vụ chỉ dẫn cách thực hiện một việc duy nhất, thường bằng cách đưa ra một chuỗi các bước ngắn.

Các tác vụ bao gồm: Cài đặt tool, chạy jobs, quản lý GPUs, etc.

Bạn có thể tạo và đóng góp tài liệu về một tác vụ mới thông qua Hướng dẫn tạo tài liệu mới.

4.1 - Cài đặt các công cụ

kubectl

Công cụ dòng lệnh Kubernetes, kubectl, cho phép bạn chạy các câu lệnh tương tác tới các cụm Kubernetes. Bạn có thể sử dụng kubectl để triển khai các ứng dụng, kiểm tra và quản lý các tài nguyên của cụm, và xem log. Để biết thêm thông tin bao gồm một danh sách đầy đủ các lệnh của kubectl, xem tài liệu tham khảo kubectl.

kubectl có thể cài đặt trên nhiều nền tảng Linux, macOS và Windows. Chọn hệ điều hành ưa thích của bạn bên dưới.

• Cài đặt kubectl trên Linux
• Cài đặt kubectl trên macOS
• Cài đặt kubectl trên Windows

kind

kind cho phép bạn chạy Kubernetes trên máy tính cục bộ của bạn. Công cụ này yêu cầu bạn phải có hoặc Docker hoăc Podman được cài đặt sẵn.

Trang Bắt đầu nhanh của kind cho bạn biết cần phải làm những gì để bắt đầu và chạy với kind.

Xem Hướng dẫn Bắt đầu nhanh của kind

minikube

Giống kind, minikube là một công cụ cho phép bạn chạy Kubernetes cục bộ. minikube chạy một cụm Kubernetes cục bộ tất-cả-trong-một hoặc nhiều-node trên máy tính cá nhân (bao gồm Windows, macOS và Linux) vì vậy bạn có thể thử Kubernetes, hoặc cho công việc phát triển hàng ngày.

Bạn có thể theo dõi hướng dẫn chính thức Bắt đầu! nếu bạn tập trung vào việc cài đặt công cụ.

Xem Hướng dẫn Bắt đầu! của minikube

Một khi bạn có minikube đang chạy, bạn có thể dùng nó để chạy một ứng dụng mẫu.

kubeadm

Bạn có thể dùng công cụ kubeadm để tạo và quản lý các cụm Kubernetes. Nó thực hiện các hành động cần thiết để có được sự khả thi tối thiểu, đảm bảo cụm khởi động và chạy theo một cách thân thiện với người dùng.

Cài đặt kubeadm hướng dẫn bạn cách để cài đặt kubeadm. Một khi được cài đặt, bạn có thể dùng nó để tạo một cụm.

Xem Hướng dẫn Cài đặt kubeadm

4.1.1 - Cài đặt và cấu hình kubectl

Công cụ command-line trong Kubernetes, kubectl, cho phép bạn thực thi các câu lệnh trong Kubernetes clusters. Bạn có thể sử dụng kubectl để triển khai các ứng dụng, theo dõi và quản lý tài nguyên của cluster, và xem log. Để biết các thao tác của kubectl, truy cập tới Tổng quan về kubectl.

Trước khi bạn bắt đầu

Bạn cần phải sử dụng phiên bản kubectl sai lệch không quá một phiên bản với version của cluster. Ví dụ, một client v1.2 nên được hoạt động với master v1.1, v1.2 và v1.3. Sử dụng phiên bản mới nhất của kubectl giúp tránh được các vấn đề không lường trước được.

Cài đặt kubectl trên Linux

Cài đặt kubectl binary với curl trên Linux

1. Tải về phiên bản mới nhất với câu lệnh:

   curl -LO https://dl.k8s.io/release/`curl -LS https://dl.k8s.io/release/stable.txt`/bin/linux/amd64/kubectl
   

   Để tải về phiên bản cụ thể, hãy thay thế phần $(curl -LS https://dl.k8s.io/release/stable.txt) trong câu lệnh với một phiên bản cụ thể.

   Ví dụ như, để tải về phiên bản 1.33.0 trên Linux, hãy nhập như sau:

   curl -LO https://dl.k8s.io/release/v1.33.0/bin/linux/amd64/kubectl
   

2. Tạo kubectl binary thực thi.

   chmod +x ./kubectl
   

3. Đưa bản binary vào biến môi trường PATH của bạn.

   sudo mv ./kubectl /usr/local/bin/kubectl
   

4. Kiểm tra chắc chắn rằng phiên bản bạn cài là mới nhất:

   kubectl version
   

Cài đặt kubectl sử dụng trình quản lý gói

• Ubuntu, Debian or HypriotOS
• CentOS, RHEL or Fedora

sudo apt-get update && sudo apt-get install -y apt-transport-https
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubectl

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
yum install -y kubectl

Cài đặt với snap

Nếu bạn đang sử dụng Ubuntu hoặc distro Linux khác hỗ trợ trình quản lý gói snap, thì kubectl đã có sẵn trong snap.

1. Chuyển sang user snap và thực thi câu lệnh cài đặt:

   sudo snap install kubectl --classic
   

2. Kiểm tra phiên bản bạn vừa cài là mới nhất:

   kubectl version
   

Cài đặt kubectl trên macOS

Cài đặt kubectl binary với curl trên macOS

1. Tải về phiên bản mới nhất:

   curl -LO "https://dl.k8s.io/release/$(curl -LS https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
   

   Để tải về phiên bản cụ thể, hãy thay thế phần $(curl -LS https://dl.k8s.io/release/stable.txt) trong câu lệnh với phiên bản cụ thể.

   Ví dụ, để tải về phiên bản 1.33.0 trên macOS, gõ:

   curl -LO https://dl.k8s.io/release/v1.33.0/bin/darwin/amd64/kubectl
   

2. Tạo kubectl binary thực thi.

   chmod +x ./kubectl
   

3. Đưa bản binary vào biến môi trường PATH của bạn.

   sudo mv ./kubectl /usr/local/bin/kubectl
   

4. Kiểm tra chắc chắn rằng phiên bản bạn cài là mới nhất:

   kubectl version
   

Cài đặt với Homebrew trên macOS

Nếu bạn đang trên macOS và sử dụng trình quản lý gói Homebrew, bạn có thể cài đặt kubectl với Homebrew.

1. Chạy câu lệnh cài đặt:

   brew install kubectl 
   

   hoặc

   brew install kubernetes-cli
   

2. Kiểm tra chắc chắn rằng phiên bản bạn cài là mới nhất:

   kubectl version
   

Cài đặt với Macports trên macOS

Nếu bạn đang trên macOS và sử dụng trình quản lý gói Macports, bạn có thể cài đặt kubectl với Macports.

1. Chạy câu lệnh cài đặt:

   sudo port selfupdate
   sudo port install kubectl
   

2. Kiểm tra chắc chắn rằng phiên bản bạn cài là mới nhất:

   kubectl version
   

Cài đặt kubectl trên Windows

Cài đặt kubectl binary với curl trên Windows

1. Tải về phiên bản mới nhất 1.33.0 từ đường dẫn này.

   Hoặc nếu bạn đã cài đặt curl, hãy sử dụng câu lệnh sau:

   curl -LO https://dl.k8s.io/release/v1.33.0/bin/windows/amd64/kubectl.exe
   

   Để tìm ra phiên bản ổn định mới nhất, hãy xem https://dl.k8s.io/release/stable.txt.

2. Đưa bản binary vào biến môi trường PATH của bạn.

3. Kiểm tra chắn chắn phiên bản kubectl giống với bản đã tải về:

   kubectl version
   

Cài đặt với Powershell từ PSGallery

Nếu bạn đang ở trên Windows và sử dụng trình quản lý gói Powershell Gallery, bạn có thể cài đặt và cập nhật kubectl với Powershell.

1. Thực thi các câu lệnh cài đặt sau (hãy đảm bảo bạn tự định nghĩa DownloadLocation):

   Install-Script -Name install-kubectl -Scope CurrentUser -Force
   install-kubectl.ps1 [-DownloadLocation <path>]
   

   Lưu ý:

   Nếu bạn không định nghĩa DownloadLocation, kubectl sẽ được cài đặt ở thư mục temp của user.

   Bản cài đặt sẽ tạo ra $HOME/.kube và hướng dẫn để tạo ra file cấu hình

2. Kiểm tra chắc chắn rằng phiên bản bạn cài là mới nhất:

   kubectl version
   

   Lưu ý:

   Cập nhật của bản cài đặt sẽ được thực hiện khi chạy lại các câu lệnh từ bước 1.

Cài đặt trên Windows sử dụng Chocolatey hoặc Scoop

Để cài đặt kubectl trên Windows bạn có thể sử dụng trình quản lý gói Chocolatey hoặc bộ cài đặt câu lệnh Scoop.

• choco
• scoop

choco install kubernetes-cli

scoop install kubectl

```
kubectl version
```

3. Di chuyển tới thư mục home của bạn:

   cd %USERPROFILE%
   

4. Tạo thư mục .kube:

   mkdir .kube
   

5. Di chuyển tới thư mục .kube bạn vừa mới tạo:

   cd .kube
   

6. Cấu hình kubectl để sử dụng Kubernetes cluster từ xa:

   New-Item config -type file
   

   Lưu ý:

   Chỉnh sửa file cấu hình với trình soạn thảo văn bản, như là Notepad.

Tải xuống từ một phần của Google Cloud SDK

Bạn có thể cài đặt kubectl từ một phần của Google Cloud SDK.

1. Cài đặt Google Cloud SDK.

2. Thực thi câu lệnh cài đặt kubectl:

   gcloud components install kubectl
   

3. Kiểm tra chắc chắn rằng phiên bản bạn cài là mới nhất:

   kubectl version
   

Xác minh cấu hình kubectl

Để kubectl tìm kiếm và truy cập Kubernetes cluster, nó cần một kubeconfig file, được tự động tạo ra khi bạn tạo mới một cluster sử dụng kube-up.sh hoặc triển khai thành công một Minikube cluster. Mặc định thì cấu hình của kubectl được xác định tại ~/.kube/config.

Kiểm tra kubectl được cấu hình đúng bằng việc xem trạng thái của cluster:

kubectl cluster-info

Nếu bạn trông thấy một URL phản hồi, thì kubectl đã được cấu hình đúng để truy cập vào cluster của bạn.

Nếu bạn trông thấy một tin nhắn tương tự bên dưới, thì kuberctl chưa được cấu hình đúng hoặc chưa thể kết nối với Kubernetes cluster.

The connection to the server <server-name:port> was refused - did you specify the right host or port?

Ví dụ như, nếu bạn đang định chạy một Kubernetes cluster trên laptop của bạn (locally), bạn sẽ cần một công cụ như Minikube được cài trước đó và chạy lại các câu lệnh bên trên.

Nếu kubectl cluster-info trả về url nhưng bạn không thể truy cập vào cluster của bạn, thì hãy kiểm tra nó đã được cấu hình đúng hay chưa, bằng cách:

kubectl cluster-info dump

Các lựa chọn cấu hình kubectl

Kích hoạt shell autocompletion

kubectl cung cấp autocompletion hỗ trợ cho Bash and Zsh, giúp bạn giảm thiểu việc phải gõ nhiều câu lệnh.

Bên dưới đâu là các bước để thiết lập autocompletion cho Bash (bao gồm sự khác nhau giữa Linux và macOS) và Zsh.

• Bash trên Linux
• Bash trên macOS
• Zsh

source /usr/share/bash-completion/bash_completion

brew install bash-completion@2

export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh"

source <(kubectl completion zsh)

echo 'alias k=kubectl' >>~/.zshrc
echo 'compdef __start_kubectl k' >>~/.zshrc

autoload -Uz compinit
compinit

Tiếp theo là gì

• Cài đặt Minikube
• Xem hướng dẫn bắt đầu để biết thêm về việc tạo cluster.
• Tìm hiểu cách khởi chạy và hiển thị ứng dụng của bạn.
• Nếu bạn cần quyền truy cập vào một cluster mà bạn không tạo, hãy xem tài liệu Sharing Cluster Access.
• Đọc tài liệu tham khảo của kubectl

4.1.2 - Cài đặt Minikube

Tài liệu này sẽ hướng dẫn các bạn cách cài đặt Minikube, một công cụ chạy một Kubernetes cluster chỉ gồm một node trong một máy ảo (VM) trên máy tính của bạn.

Trước khi bạn bắt đầu

• Linux
• macOS
• Windows

grep -E --color 'vmx|svm' /proc/cpuinfo

sysctl -a | grep -E --color 'machdep.cpu.features|VMX' 

systeminfo

Hyper-V Requirements:     VM Monitor Mode Extensions: Yes
                          Virtualization Enabled In Firmware: Yes
                          Second Level Address Translation: Yes
                          Data Execution Prevention Available: Yes

Hyper-V Requirements:     A hypervisor has been detected. Features required for Hyper-V will not be displayed.

Cài đặt minikube

• Linux
• macOS
• Windows

curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \
  && chmod +x minikube

sudo mkdir -p /usr/local/bin/
sudo install minikube /usr/local/bin/

brew install minikube

brew install minikube

curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \
  && chmod +x minikube

sudo mv minikube /usr/local/bin

choco install minikube

Dọn dẹp local state

Nếu bạn đã cài Minikube trước đó, và chạy:

minikube start

và tiếp đó minikube start trả về lỗi:

machine does not exist

thì tiếp theo bạn cần xóa bỏ local state của minikube:

minikube delete

Tiếp theo là gì

• Chạy Kubernetes trên local thông qua Minikube

4.2 - Cấu hình Pods và Containers

4.2.1 - Cấp phát tài nguyên bộ nhớ cho Containers và Pods

Trang này hướng dẫn cách cấp phát bộ nhớ request (tối thiểu) và bộ nhớ limit (tối đa) cho một Container. Một Container được đảm bảo có đủ bộ nhớ như nó yêu cầu, nhưng không được phép sử dụng nhiều bộ nhớ hơn giới hạn của nó.

Trước khi bạn bắt đầu

Bạn cần có một cluster Kubernetes, và kubectl phải được cấu hình để giao tiếp với cluster của bạn. Khuyến nghị nên chạy hướng dẫn này trên một cluster có ít nhất hai node không đóng vai trò là máy chủ control plane. Nếu bạn chưa có cluster, bạn có thể tạo một cluster bằng cách sử dụng minikube hoặc sử dụng một trong các sân chơi Kubernetes sau:

• Killercoda
• KodeKloud
• Play with Kubernetes

Để kiểm tra phiên bản của kubectl, hãy chạy lệnh kubectl version.

Để kiểm tra phiên bản, nhập kubectl version.

Mỗi Node trong Cluster của bạn phải có ít nhất 300 MiB bộ nhớ.

Một số bước trong trang này yêu cầu bạn chạy dịch vụ metrics-server trong Cluster. Nếu bạn đã có metrics-server đang chạy, bạn có thể bỏ qua các bước này.

Nếu bạn đang chạy Minikube, hãy chạy lệnh sau để bật metrics-server:

minikube addons enable metrics-server

Để kiểm tra xem metrics-server có đang chạy hay không, hoặc hệ thống giám sát tài nguyên khác (metrics.k8s.io), hãy chạy lệnh sau:

kubectl get apiservices

Nếu hệ thống giám sát tài nguyên có sẵn, kết quả sẽ chứa metrics.k8s.io.

NAME
v1beta1.metrics.k8s.io

Tạo namespace

Tạo một namespace để các tài nguyên mà bạn tạo trong bài này được tách biệt khỏi phần còn lại của cluster.

kubectl create namespace mem-example

Cài đặt bộ nhớ tối thiểu và bộ nhớ tối đa

Để cài đặt bộ nhớ tối thiểu cho một Container, bạn cần thêm trường resources:requests vào phần khai báo trong tệp cấu hình Container. Với bộ nhớ tối đa, bạn hãy thêm resources:limits.

Trong phần thực hành này, bạn sẽ tạo một Pod có một Container. Container này có bộ nhớ tối thiểu là 100 MiB và bộ nhớ tối đa là 200 MiB. Đây là file cấu hình cho Pod:

pods/resource/memory-request-limit.yaml

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "100Mi"
      limits:
        memory: "200Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]

Phần args trong tệp cấu hình cung cấp các tham số cho Container khi nó khởi tạo. Các tham số "--vm-bytes", "150M" yêu cầu Container cấp phát 150 MiB bộ nhớ.

Tạo Pod:

kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit.yaml --namespace=mem-example

Kiểm tra Pod đang chạy:

kubectl get pod memory-demo --namespace=mem-example

Xem thông tin chi tiết về Pod:

kubectl get pod memory-demo --output=yaml --namespace=mem-example

Kết quả cho thấy Container trong Pod có bộ nhớ tối thiểu là 100 MiB và bộ nhớ tối đa là 200 MiB.

...
resources:
  requests:
    memory: 100Mi
  limits:
    memory: 200Mi
...

Chạy lệnh kubectl top để xem các thông số của Pod:

kubectl top pod memory-demo --namespace=mem-example

Kết quả cho thấy Pod đang sử dụng khoảng 162,900,000 bytes bộ nhớ, tương đương khoảng 150MiB. Mức này cao hơn 100MiB tối thiểu nhưng vẫn nằm trong giới hạn 200MiB.

NAME                        CPU(cores)   MEMORY(bytes)
memory-demo                 <something>  162856960

Xóa Pod:

kubectl delete pod memory-demo --namespace=mem-example

Vượt quá bộ nhớ tối đa của Container

Một Container có thể sử dụng nhiều bộ nhớ hơn mức tối thiểu nếu Node còn bộ nhớ trống. Tuy nhiên, Container không được phép sử dụng bộ nhớ hơn mức tối đa của nó. Nếu Container cấp phát nhiều bộ nhớ hơn mức tối đa, Container đó sẽ có khả năng bị dừng hoạt động. Nếu Container tiếp tục sử dụng bộ nhớ vượt quá giới hạn, nó sẽ được dừng hoàn toàn. Nếu Container đó có thể khởi động lại, kubelet sẽ khởi động lại nó, lỗi quá bộ nhớ được xử lý giống như đối với các lỗi runtime khác.

Trong phần thực hành này, bạn sẽ tạo một Pod cố gắng cấp phát bộ nhớ nhiều hơn giới hạn của nó. Đây là tệp cấu hình cho một Pod có một Container với bộ nhớ tối thiểu là 50 MiB và bộ nhớ tối đa là 100 MiB:

pods/resource/memory-request-limit-2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo-2
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-2-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "50Mi"
      limits:
        memory: "100Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "250M", "--vm-hang", "1"]

Trong phần args của tệp cấu hình, bạn có thể thấy Container sẽ cố gắng cấp phát 250 MiB bộ nhớ, vượt xa giới hạn 100 MiB.

Tạo Pod:

kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-2.yaml --namespace=mem-example

Xem thông tin chi tiết Pod:

kubectl get pod memory-demo-2 --namespace=mem-example

Tại thời điểm này, Container có thể đang chạy hoặc đã được dừng hoạt động. Lặp lại lệnh trước đó cho đến khi Container dừng hoạt động:

NAME            READY     STATUS      RESTARTS   AGE
memory-demo-2   0/1       OOMKilled   1          24s

Xem chi tiết hơn về trạng thái của Container:

kubectl get pod memory-demo-2 --output=yaml --namespace=mem-example

Kết quả cho thấy Container đã dừng hoạt động vì hết bộ nhớ (OOM - Out Of Memory):

lastState:
   terminated:
     containerID: 65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f
     exitCode: 137
     finishedAt: 2017-06-20T20:52:19Z
     reason: OOMKilled
     startedAt: null

Container trong phần thực hành này có thể được khởi động lại, vì vậy kubelet sẽ khởi động lại nó. Lặp lại lệnh này vài lần để thấy Container liên tục bị dừng hoạt động và khởi động lại:

kubectl get pod memory-demo-2 --namespace=mem-example

Kết quả cho thấy Container bị dừng hoạt động, khởi động lại, bị dừng hoạt động lần nữa, khởi động lại lần nữa, và cứ tiếp tục như vậy:

kubectl get pod memory-demo-2 --namespace=mem-example
NAME            READY     STATUS      RESTARTS   AGE
memory-demo-2   0/1       OOMKilled   1          37s

kubectl get pod memory-demo-2 --namespace=mem-example
NAME            READY     STATUS    RESTARTS   AGE
memory-demo-2   1/1       Running   2          40s

Xem thông tin chi tiết về lịch sử của Pod:

kubectl describe pod memory-demo-2 --namespace=mem-example

Kết quả cho thấy Container liên tục khởi động và thất bại:

... Normal  Created   Created container with id 66a3a20aa7980e61be4922780bf9d24d1a1d8b7395c09861225b0eba1b1f8511
... Warning BackOff   Back-off restarting failed container

Xem thông tin chi tiết về các Node trong Cluster:

kubectl describe nodes

Kết quả cho thấy việc Container bị dừng hoạt động do tình trạng hết bộ nhớ:

Warning OOMKilling Memory cgroup out of memory: Kill process 4481 (stress) score 1994 or sacrifice child

Xóa Pod:

kubectl delete pod memory-demo-2 --namespace=mem-example

Cài đặt bộ nhớ tối thiểu vượt quá khả năng của Nodes

Bộ nhớ tối thiểu và tối đa được gắn với các Container, nhưng cũng có thể hiểu rằng một Pod có tổng bộ nhớ tối thiểu và tối đa riêng. Bộ nhớ tối thiểu cho Pod là tổng các bộ nhớ tối thiểu của tất cả các Container trong Pod. Tương tự, bộ nhớ tối đa cho Pod là tổng của các bộ nhớ tối đa của tất cả các Container trong Pod.

Khi lập lịch (scheduling) Pod, Kubernetes dựa vào bộ nhớ tối thiểu. Một Pod chỉ được chạy trên Node nếu Node có đủ bộ nhớ trống để đáp ứng bộ nhớ tối thiểu của Pod.

Trong phần thực hành này, bạn sẽ tạo một Pod có bộ nhớ tối thiểu lớn đến mức vượt quá khả năng của bất kỳ Node nào trong cluster của bạn. Đây là tệp cấu hình cho một Pod có một Container với 1000 GiB bộ nhớ tối thiểu, có khả năng vượt quá khả năng của bất kỳ Node nào trong cluster của bạn.

pods/resource/memory-request-limit-3.yaml

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo-3
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-3-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "1000Gi"
      limits:
        memory: "1000Gi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]

Khởi tạo Pod:

kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-3.yaml --namespace=mem-example

Xem trạng thái của Pod:

kubectl get pod memory-demo-3 --namespace=mem-example

Kết quả cho thấy trạng thái của Pod là PENDING. Nghĩa là, Pod không được lập lịch để chạy trên bất kỳ Node nào, và nó sẽ tiếp tục ở trạng thái PENDING vô thời hạn:

kubectl get pod memory-demo-3 --namespace=mem-example
NAME            READY     STATUS    RESTARTS   AGE
memory-demo-3   0/1       Pending   0          25s

Xem thông tin chi tiết về Pod, bao gồm cả sự kiện:

kubectl describe pod memory-demo-3 --namespace=mem-example

Kết quả cho thấy Container không thể được lập lịch do không đủ bộ nhớ trên các Nodes:

Events:
  ...  Reason            Message
       ------            -------
  ...  FailedScheduling  No nodes are available that match all of the following predicates:: Insufficient memory (3).

Đơn vị đo bộ nhớ

Tài nguyên bộ nhớ được đo bằng byte. Bạn có thể biểu thị bộ nhớ dưới dạng số nguyên thông thường hoặc số thập phân cố định với một trong các hậu tố sau: E, P, T, G, M, K, Ei, Pi, Ti, Gi, Mi, Ki. Ví dụ, các giá trị sau đây biểu thị xấp xỉ cùng một giá trị:

128974848, 129e6, 129M, 123Mi

Xoá Pod:

kubectl delete pod memory-demo-3 --namespace=mem-example

Nếu bạn không cài đặt bộ nhớ tối đa

Nếu bạn không cài đặt bộ nhớ tối đa cho một Container, một trong các tình huống sau sẽ xảy ra:

• Container không có giới hạn tối đa về lượng bộ nhớ mà nó sử dụng. Container có thể sử dụng tất cả bộ nhớ có sẵn trên Node nơi nó đang chạy, điều này có thể kích hoạt OOM Killer. Hơn nữa, trong trường hợp OOM Kill, một container không có giới hạn tài nguyên sẽ có khả năng bị dừng hoạt động cao hơn.

• Container đang chạy trong một namespace có bộ nhớ tối đa mặc định, và Container tự động được gán giới hạn mặc định đó. Cluster administrators có thể sử dụng LimitRange để chỉ định giá trị mặc định cho bộ nhớ tối đa.

Lý do cần có bộ nhớ tối thiểu và bộ nhớ tối đa

Bằng cách cấu hình bộ nhớ tối thiểu và tối đa cho các Container chạy trong cluster của bạn, bạn có thể sử dụng hiệu quả tài nguyên bộ nhớ có sẵn trên các Node của cluster. Với việc giữ bộ nhớ tối thiểu của Pod ở mức thấp, Pod dễ được triển khai hơn. Bằng cách có bộ nhớ tối đa lớn hơn bộ nhớ tối thiểu, bạn đạt được hai điều:

• Pod có thể có các đợt hoạt động cao điểm sử dụng bộ nhớ đang có sẵn.
• Lượng bộ nhớ mà Pod có thể sử dụng trong đợt cao điểm được giới hạn ở một mức hợp lý.

Xóa các thành phần đã tạo

Xóa namespace của bạn. Thao tác này sẽ xóa tất cả các Pod bạn đã tạo cho phần này:

kubectl delete namespace mem-example

Tiếp theo là gì

Dành cho nhà phát triển ứng dụng

• Cấp phát tài nguyên CPU cho Containers và Pods

• Cấp phát tài nguyên CPU và bộ nhớ ở cấp độ Pod

• Cấu hình chất lượng dịch vụ (QoS) cho Pods

Dành cho quản trị viên cluster

• Thiết lập bộ nhớ mặc định tối thiểu và tối đa cho một Namespace

• Thiết lập CPU mặc định tối thiểu và tối đa cho một Namespace

• Thiết lập giới hạn bộ nhớ tối thiểu và tối đa cho Namespace

• Thiết lập giới hạn CPU tối thiểu và tối đa cho Namespace

• Thiết lập giới hạn tài nguyên CPU và bộ nhớ cho Namespace

• Thiết lập giới hạn số lượng Pod trong Namespace

• Thiết lập giới hạn cho các đối tượng API

• Thay đổi kích thước CPU và bộ nhớ được cấp cho Containers

5 - Tutorials

Phần này của tài liệu có chứa các hướng dẫn. Phần hướng dẫn sẽ chỉ cho bạn cách thực hiện một mục tiêu lớn hơn một tác vụ đơn lẻ.

Thông thường, một hướng dẫn có nhiều phần, mỗi phần có một trình tự các bước. Trước khi thực hiện từng hướng dẫn, bạn có thể muốn đánh dấu trang Thuật ngữ chuẩn hóa để tham khảo.

5.1 - Học kiến thức cơ bản về Kubernetes

Kiến thức cơ bản về Kubernetes

Hướng dẫn này cung cấp những kiến thức cơ bản về một cụm Kubernetes. Mỗi mô-đun chứa một số thông tin cơ bản về các tính năng cũng như khái niệm chính của Kubernetes, đồng thời bao gồm một hướng dẫn tương tác trực tuyến. Các hướng dẫn tương tác này giúp bạn quản lý một cluster đơn giản và các ứng dụng được đóng gói của bạn.

Bằng các hướng dẫn tương tác, bạn có thể học cách:

• Triển khai một ứng dụng container trong một cluster.
• Thay đổi quy mô triển khai.
• Cập nhật ứng dụng container.
• Debug ứng dụng container.

Những hướng dẫn này dùng Katacoda để chạy một terminal ảo trên trình duyệt web của bạn chạy Minikube. Không cần phải cài đặt và cấu hình bất kỳ phần mềm nào; mỗi hướng dẫn tương tác chạy trực tiếp từ trình duyệt web của bạn.

Kubernetes có thế làm những gì?

Với các dịch vụ web hiện đại, người dùng mong muốn các ứng dụng luôn sẵn sàng hoạt động 24/7 và các lập trình viên muốn triển khai các phiên bản của ứng dụng đó nhiều lần trong ngày. Việc đóng gói ứng dụng vào container giúp giải quyết mục tiêu này, cho phép các ứng dụng được phát hành và cập nhật một cách dễ dàng, nhanh chóng mà không có downtime. Kubernetes giúp bạn đảm bảo các ứng dụng container chạy ở bất kì đâu và bất kì lúc nào bạn muốn, đồng thời giúp chúng tìm thấy các tài nguyên và công cụ cần thiết để chạy. Kubernetes là nền tảng mã nguồn mở, chạy được trong môi trường production, được thiết kế và phát triển bởi Google, kết hợp với những ý tưởng tốt nhất từ cộng đồng.

Những mô-đun Kubernetes cơ bản

1. Tạo mới một cụm Kubernetes

2. Triển khai ứng dụng

3. Khám phá ứng dụng

4. Đưa ứng dụng ra public

5. Scale ứng dụng

6. Cập nhật ứng dụng

5.1.1 - Tạo một Cluster

5.1.1.1 - Sử dụng Minikube để tạo một Cluster

5.1.1.2 - Hướng dẫn tương tác - Tạo một Cluster

5.1.2 - Triển khai một ứng dụng

5.1.2.1 - Sử dụng kubectl để triển khai ứng dụng

5.1.2.2 - Hướng dẫn tương tác - Triển khai một ứng dụng

5.1.3 - Khám phá ứng dụng

5.1.3.1 - Khám Phá Pods Và Nodes

5.1.3.2 - Hướng dẫn tương tác - Khám phá ứng dụng

6 - Tài liệu tham khảo

Phần này chứa các tài liệu tham khảo của Kubernetes.

6.1 - Thuật ngữ chuẩn hóa

6.2 - kubectl Cheat Sheet

Xem thêm: Kubectl Overview và JsonPath Guide.

Trang này là trang tổng quan của lệnh kubectl.

kubectl - Cheat Sheet

Kubectl Autocomplete

BASH

source <(kubectl completion bash) # thiết lập autocomplete trong bash vào shell hiện tại, gói bash-completion nên được cài đặt trước tiên 
echo "source <(kubectl completion bash)" >> ~/.bashrc # thêm vĩnh viễn autocomplete vào trong bash shell

Bạn có thể dùng một alias cho kubectl cũng hoạt động với completion:

alias k=kubectl
complete -F __start_kubectl k

ZSH

source <(kubectl completion zsh)  # thiết lập autocomplete trong zsh vào shell hiện tại
echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # thêm vĩnh viễn autocomplete vào trong zsh shell

Ngữ cảnh và cấu hình kubectl

Thiết lập cụm Kubernetes nào mà kubectl sẽ giao tiếp với và sửa đổi thông tin cấu hình. Xem tài liệu Xác thực giữa các cụm với kubeconfig để biết thông tin chi tiết của tệp cấu hình.

kubectl config view # Hiển thị các thiết lập kubeconfig đã được merged

# sử dụng nhiều tệp kubeconfig cùng một lúc và xem cấu hình hợp nhất
KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 

kubectl config view

# lấy mật khẩu cho người dùng e2e
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'

kubectl config view -o jsonpath='{.users[].name}'    # hiển thị người dùng đầu tiên  
kubectl config view -o jsonpath='{.users[*].name}'   # lấy danh sách người dùng  
kubectl config get-contexts                          # hiển thị danh sách các ngữ cảnh 
kubectl config current-context                       # hiển thị ngữ cảnh hiện tại
kubectl config use-context my-cluster-name           # thiết lập ngữ cảnh mặc định cho my-cluster-name

# thêm một cụm mới vào kubeconf hỗ trợ xác thực cơ bản
kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword

# lưu vĩnh viễn namespace cho tất cả các lệnh kubectl tiếp theo trong ngữ cảnh đó
kubectl config set-context --current --namespace=ggckad-s2

# thiết lập ngữ cảnh sử dụng tên người dùng và namespace cụ thể
kubectl config set-context gce --user=cluster-admin --namespace=foo \
  && kubectl config use-context gce
 
kubectl config unset users.foo                       # xóa người dùng foo

Apply

apply quản lý các ứng dụng thông qua các tệp định nghĩa tài nguyên Kubernetes. Nó tạo và cập nhật các tài nguyên trong một cụm thông qua việc chạy kubectl apply. Đây là cách được đề xuất để quản lý các ứng dụng Kubernetes trong thực tế. Xem thêm Kubectl Book.

Tạo một đối tượng

Kubernetes manifests có thể được định nghĩa trong tệp json hoặc yaml. Phần mở rộng .yaml, .yml, và .json có thể được dùng.

kubectl apply -f ./my-manifest.yaml            # tạo tài nguyên
kubectl apply -f ./my1.yaml -f ./my2.yaml      # tạo từ nhiều tệp
kubectl apply -f ./dir                         # tạo tài nguyên từ tất cả các tệp manifest trong thư mục dir
kubectl apply -f https://git.io/vPieo          # tạo tài nguyên từ url
kubectl create deployment nginx --image=nginx  # tạo một deployment nginx
kubectl explain pods,svc                       # lấy thông tin pod và service manifest

# Tạo nhiều đối tượng YAML từ stdin
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-sleep
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
---
apiVersion: v1
kind: Pod
metadata:
  name: busybox-sleep-less
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000"
EOF

# Tạo một secret với một số keys
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  password: $(echo -n "s33msi4" | base64 -w0)
  username: $(echo -n "jane" | base64 -w0)
EOF

Xem, tìm các tài nguyên

# Lệnh get với một số đầu ra cơ bản
kubectl get services                          # Liệt kê tất cả các services trong namespace
kubectl get pods --all-namespaces             # Liệt kê tất cả các pods trong tất cả các namespaces
kubectl get pods -o wide                      # Liệt kê tất cả các pods namespace, với nhiều thông tin hơn
kubectl get deployment my-dep                 # Liệt kê một deployment cụ thể
kubectl get pods                              # Liệt kê tất cả các pods trong namespace
kubectl get pod my-pod -o yaml                # Lấy thông tin của một pod ở dạng YAML
kubectl get pod my-pod -o yaml --export       # Lấy thông tin của một pod ở dạng YAML mà không có thông tin cụ thể về cụm

# Lệnh describe
kubectl describe nodes my-node
kubectl describe pods my-pod

# Liệt kê các services được sắp xếp theo tên
kubectl get services --sort-by=.metadata.name

# Liệt kê các pods được sắp xếp theo số lần khởi động lại
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'

# Liệt kê các pods được sắp xếp theo dung lượng trong namespace có tên là test

kubectl get pods -n test --sort-by='.spec.capacity.storage'

# Lấy thông tin phiên bản của tất cả các pods có nhãn app=cassandra
kubectl get pods --selector=app=cassandra -o \
  jsonpath='{.items[*].metadata.labels.version}'

# Liệt kê tất cả các worker nodes (sử dụng một selector để loại trừ kết quả có một nhãn
# có tên 'node-role.kubernetes.io/master'  
kubectl get node --selector='!node-role.kubernetes.io/master'

# Liệt kê tất cả các pods đang chạy trong namespace
kubectl get pods --field-selector=status.phase=Running

# Liệt kê tất cả các ExternalIPs của tất cả các nodes
kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'

# Liệt kê tên của các pods thuộc về một RC nhất định
# Lệnh "jq" hữu ích cho các chuyển đổi quá mức phức tạp cho jsonpath, xem thêm tại https://stedolan.github.io/jq/
sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?}
echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})

# Hiển thị nhãn của tất cả các pods (hoặc các đối tượng Kubernetes khác hỗ trợ gán nhãn)
kubectl get pods --show-labels

# Kiểm tra xem nodes nào đã sẵn sàng
JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
 && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"

# Liệt kê tất cả cá Secrets hiện đang sử dụng bởi một pod
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq

# Liệt kê tất cả các sự kiện được sắp xếp theo thời gian
kubectl get events --sort-by=.metadata.creationTimestamp

Cập nhật các tài nguyên

Theo như phiên bản 1.11, rolling-update đã không còn được dùng nữa (xem CHANGELOG-1.11.md), sử dụng rollout thay thế.

kubectl set image deployment/frontend www=image:v2               # Cập nhận container "www" của deployment "frontend", cập nhật image
kubectl rollout history deployment/frontend                      # Kiểm tra lịch sử deployment bao gồm các sửa đổi
kubectl rollout undo deployment/frontend                         # Quay trở lại deployment trước đó
kubectl rollout undo deployment/frontend --to-revision=2         # Quay trở lại một phiên bản cụ thể
kubectl rollout status -w deployment/frontend                    # Xem trạng thái cập nhật của deployment "frontend" cho đến khi hoàn thành


# không còn được sử dụng kể từ phiên bản 1.11
kubectl rolling-update frontend-v1 -f frontend-v2.json           # (không dùng nữa) Cập nhật pods của frontend-v1
kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2  # (không dùng nữa) Đổi tên tài nguyên và cập nhật image 
kubectl rolling-update frontend --image=image:v2                 # (không dùng nữa) Cập nhật image của pod của frontend
kubectl rolling-update frontend-v1 frontend-v2 --rollback        # (không dùng nữa) Hủy bỏ tiến trình cập nhật hiện tại

cat pod.json | kubectl replace -f -                              # Thay thế một pod dựa trên JSON được truyền vào std

# Buộc thay thế, xóa và sau đó tạo lại tài nguyên, sẽ gây ra sự cố ngưng services
kubectl replace --force -f ./pod.json

# Tạo một services cho nginx, phục vụ trên công 80 và kết nối đến các container trên cổng 8000
kubectl expose rc nginx --port=80 --target-port=8000

# Cập nhật phiên bản image của một container đơn lẻ lên v4 
kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -

kubectl label pods my-pod new-label=awesome                      # Thêm một nhãn
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq       # Thêm một chú thích
kubectl autoscale deployment foo --min=2 --max=10                # Tự động scale deployment "foo"

Vá các tài nguyên

# Cập nhật một phần một node
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'

# Cập nhật image của container; spec.containers[*].name là bắt buộc vì đó là khóa hợp nhất
kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'

# Cập nhật image của container sử dụng một bản vá json với các mảng vị trí
kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'

# Vô hiệu hóa một deployment livenessProbe sử dụng một bản vá json với các mảng vị trí
kubectl patch deployment valid-deployment  --type json   -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'

# Thêm một phần tử mới vào một mảng vị trí
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'

Chỉnh sửa các tài nguyên

Chỉnh sửa bất kì API tài nguyên nào trong trình soạn thảo ưa thích của bạn.

kubectl edit svc/docker-registry                      # Chỉnh sửa services có tên docker-registry
KUBE_EDITOR="nano" kubectl edit svc/docker-registry   # Sử dụng một trình soạn thảo thay thế

Scaling tài nguyên

kubectl scale --replicas=3 rs/foo                                 # Scale một replicaset có tên 'foo' thành 3
kubectl scale --replicas=3 -f foo.yaml                            # Scale một tài nguyên được xác định trong "foo.yaml" thành 3
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql  # Nếu kích thước hiện tại của deployment mysql là 2, scale mysql thành 3
kubectl scale --replicas=5 rc/foo rc/bar rc/baz                   # Scale nhiều replication controllers

Xóa tài nguyên

kubectl delete -f ./pod.json                                              # Xóa một pod sử dụng loại và tên được xác định trong pod.json
kubectl delete pod,service baz foo                                        # Xóa pods và services có tên "baz" và "foo"
kubectl delete pods,services -l name=myLabel                              # Xóa pods và services có nhãn name=myLabel
kubectl -n my-ns delete pod,svc --all                                     # Xóa tất cả pods và services trong namespace my-ns,
# Xóa tất cả pods matching với pattern1 hoặc pattern2
kubectl get pods  -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs  kubectl delete -n mynamespace pod

Tương tác với các pods đang chạy

kubectl logs my-pod                                 # kết xuất logs của pod (stdout)
kubectl logs -l name=myLabel                        # kết xuất logs của pod có nhãn name=myLabel (stdout)
kubectl logs my-pod --previous                      # kết xuất logs của pod (stdout) cho khởi tạo trước của một container
kubectl logs my-pod -c my-container                 # kết xuất logs của container của pod (stdout, trường hợp có nhiều container)
kubectl logs -l name=myLabel -c my-container        # kết xuất logs của container có tên my-container và có nhãn name=myLabel (stdout)
kubectl logs my-pod -c my-container --previous      # kết xuất logs của container my-container của pod my-pod (stdout, trường hợp có nhiều container) cho khởi tạo trước của một container
kubectl logs -f my-pod                              # lấy logs của pod my-pod (stdout)
kubectl logs -f my-pod -c my-container              # lấy logs của container my-container trong pod my-pod (stdout, trường hợp nhiều container)
kubectl logs -f -l name=myLabel --all-containers    # lấy logs của tất cả các container của pod có nhãn name=myLabel (stdout)
kubectl run -i --tty busybox --image=busybox -- sh  # Chạy pod trong một shell tương tác
kubectl run nginx --image=nginx --restart=Never -n 
mynamespace                                         # Chạy pod nginx trong một namespace cụ thể
kubectl run nginx --image=nginx --restart=Never     # Chạy pod nginx và ghi spec của nó vào file có tên pod.yaml
--dry-run -o yaml > pod.yaml

kubectl attach my-pod -i                            # Đính kèm với container đang chạy
kubectl port-forward my-pod 5000:6000               # Lắng nghe trên cổng 5000 của máy local và chuyển tiếp sang cổng 6000 trên pod my-pod
kubectl exec my-pod -- ls /                         # Chạy lệnh trong một pod (trường hợp 1 container)
kubectl exec my-pod -c my-container -- ls /         # Chạy lệnh trong pod (trường hợp nhiều container)
kubectl top pod POD_NAME --containers               # Hiển thị số liệu của pod và container chạy trong nó

Tương tác với các nodes và cụm

kubectl cordon my-node                                                # Đánh dấu my-node là không thể lập lịch
kubectl drain my-node                                                 # Gỡ my-node ra khỏi cụm để chuẩn bị cho việc bảo trì
kubectl uncordon my-node                                              # Đánh dấu my-node có thể lập lịch trở lại
kubectl top node my-node                                              # Hiển thị số liệu của node
kubectl cluster-info                                                  # Hiển thị địa chỉ master và các services
kubectl cluster-info dump                                             # Kết xuất trạng thái hiện tại của cụm ra ngoài stdout
kubectl cluster-info dump --output-directory=/path/to/cluster-state   # Kết xuất trạng thái hiện tại của cụm vào /path/to/cluster-state

kubectl taint nodes foo dedicated=special-user:NoSchedule

Các loại tài nguyên

Liệt kê tất cả các loại tài nguyên được hỗ trợ cùng với tên viết tắt của chúng, API group, cho dù chúng là namespaced, và Kind:

kubectl api-resources

Các hoạt động khác để khám phá các tài nguyên API:

kubectl api-resources --namespaced=true      # Tất cả các tài nguyên được đặt tên
kubectl api-resources --namespaced=false     # Tất cả các tài nguyên không được đặt tên
kubectl api-resources -o name                # Tất cả các tài nguyên với đầu ra đơn giản (chỉ gồm tên tài nguyên)
kubectl api-resources -o wide                # Tất cả các tài nguyên với đầu ra mở rộng
kubectl api-resources --verbs=list,get       # Tất cả các tài nguyên hỗ trợ yêu cầu "list" và "get"
kubectl api-resources --api-group=extensions # Tất cả tài nguyên trong nhóm API "tiện ích mở rộng"

Định dạng đầu ra

Để xuất thông tin chi tiết ra cửa sổ terminal của bạn theo một định dạng cụ thể, bạn có thể thêm các cờ -o hoặc --output vào lệnh kubectl được hỗ trợ.

Kubectl output verbosity and debugging

Kubectl verbosity được kiểm soát bởi cờ -v or --v theo sau là một số nguyên biểu thị mức log. Các quy ước ghi logs của Kubernetes và các mức logs liên quan được mô tả ở đây.

Tiếp theo là gì

• Đọc thêm về Tổng quan kubectl.

• Xem các tùy chọn kubectl.

• kubectl Usage Conventions để hiểu làm thế nào để sử dụng kubectl trong các kịch bản có thể tái sử dụng.

• Xem thêm bản cộng đồng kubectl cheatsheets.

7 - Đóng góp cho Kubernetes

Có rất nhiều cách để đóng góp cho Kubernetes. Bạn có thể tham gia thiết kế cho các tính năng mới, viết tài liệu cho mã nguồn hiện có, hoặc viết cho blog của chúng tôi. Còn nhiều hơn nữa: bạn có thể triển khai các tính năng mới hoặc sửa lỗi. Bạn cũng có thể giúp mọi người tham gia vào cộng đồng những người đóng góp của chúng tôi, hoặc hỗ trợ những người đóng góp hiện tại.

Với tất cả những cách khác nhau để tạo ra sự khác biệt cho dự án, chúng tôi - Kubernetes - đã tạo ra một trang web riêng: https://k8s.dev/. Bạn có thể truy cập vào đó để tìm hiểu thêm về việc đóng góp cho Kubernetes.

Nếu bạn muốn tìm hiểu cụ thể về việc đóng góp cho tài liệu hoặc các phần khác của trang web này, hãy đọc Đóng góp cho tài liệu Kubernetes. Nếu bạn muốn giúp đỡ với blog chính thức của Kubernetes, hãy đọc Đóng góp cho blog Kubernetes.

Bạn cũng có thể đọc trang của CNCF về việc đóng góp cho Kubernetes.