Có rất nhiều tài liệu tham khảo trên Internet, nhưng đôi khi lời khuyên đơn giản nhất lại có giá trị nhất. Đội đã dịch , mà tác giả bài viết sưu tầm được sau một năm làm việc với Kubernetes. Các mẹo không được sắp xếp theo mức độ quan trọng nhưng chúng tôi nghĩ rằng mọi người sẽ tìm thấy điều gì đó hữu ích cho mình.
Lệnh đơn giản nhất để làm việc với Kubernetes
Đầu tiên, có lẽ là hành động đơn giản và hữu ích nhất khi làm việc với Kubernetes. Lệnh sau cho phép hoàn thành lệnh kubectl trong vỏ bash:
echo "source <(kubectl completion bash)" >> ~/.bashrc
Tự động điền kubectl sẽ được ghi vào tệp .bashrc và sẽ được kích hoạt tự động mỗi khi shell được khởi động. Điều này tăng tốc độ gõ các lệnh và tham số dài như all-namespaces. Thêm chi tiết trong .
Giới hạn bộ nhớ và CPU mặc định trong một không gian tên
Ví dụ: nếu ứng dụng được viết không chính xác, nó sẽ mở một kết nối mới tới cơ sở dữ liệu mỗi giây nhưng không bao giờ đóng nó, thì cụm đó đã bị rò rỉ bộ nhớ. Và nếu ứng dụng không được đặt giới hạn bộ nhớ trong quá trình triển khai, điều này có thể dẫn đến lỗi nút.
Để ngăn chặn điều này, Kubernetes cho phép bạn đặt các hạn chế mặc định trên cơ sở mỗi không gian tên. Chúng được ghi trong tệp yaml cho một không gian tên cụ thể. Đây là một ví dụ về một tập tin như vậy:
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
Tạo yaml như vậy và áp dụng cho bất kỳ không gian tên nào. Ví dụ: vào không gian tên limit-example. Giờ đây, bất kỳ vùng chứa nào được triển khai trong không gian tên này sẽ có giới hạn là 512Mi, trừ khi một giới hạn riêng lẻ khác được đặt bổ sung cho vùng chứa này.
Thu gom rác trong các phiên bản cũ hơn của Kubernetes
Kubelet theo mặc định bắt đầu thu gom rác khi var/lib/docker chiếm 90% dung lượng đĩa trống. Tuy nhiên, điều này thật tuyệt vời cho đến khi Kubernetes 1.7 không có giới hạn mặc định về số lượng inode được sử dụng, tương ứng với số lượng tệp trong hệ thống tệp.
Có khả năng là vùng chứa của bạn var/lib/docker có thể chỉ sử dụng 50% dung lượng ổ đĩa nhưng có thể hết inode, điều này sẽ gây khó khăn cho người lao động.
Trong các phiên bản kubelet cũ hơn từ 1.4 đến 1.6, bạn sẽ phải thêm cờ này:
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
Trong phiên bản 1.7 trở lên, cờ này được đặt theo mặc định. Tuy nhiên, các phiên bản trước không giám sát giới hạn inode.
Minikube... Kubernetes cục bộ nhỏ nhưng mạnh mẽ
Minikube là cách dễ nhất để chạy cụm Kubernetes cục bộ. Nó được khởi chạy bằng một lệnh đơn giản:
minikube start
Việc chạy lệnh này sẽ dẫn đến một cụm Kubernetes thực sự chạy trên máy của bạn.
Bí quyết là làm thế nào để xây dựng ứng dụng và chạy nó cục bộ trên cụm đó. Trừ khi được hướng dẫn cụ thể, hình ảnh Docker sẽ được xây dựng trên máy tính của bạn chứ không phải trên cụm.
Để buộc Docker đẩy image vào cụm Kubernetes cục bộ, máy docker được đưa ra lệnh sau:
eval $(minikube docker-env)
Bây giờ chúng ta có thể xây dựng các ứng dụng trên cụm Kubernetes cục bộ.
Không cấp quyền truy cập kubectl cho mọi người
Điều này có vẻ hiển nhiên, nhưng nếu nhiều nhóm đang sử dụng cùng một cụm cho ứng dụng của họ (đó là mục đích mà Kubernetes được tạo ra), bạn không nên chỉ cung cấp cho mọi người kubectl. Tốt hơn là nên tách các lệnh ra, gán cho mỗi lệnh một không gian tên riêng và hạn chế quyền truy cập bằng các chính sách RBAC.
Bạn có thể bị nhầm lẫn khi gán quyền truy cập, đọc, tạo, xóa và các hoạt động khác cho từng nhóm. Nhưng điều chính là hạn chế quyền truy cập vào các bí mật, chỉ cho phép quản trị viên. Bằng cách này, chúng tôi sẽ phân biệt giữa những người có thể quản lý cụm và những người có thể triển khai cụm đó một cách đơn giản.
Quản lý ngân sách nhóm
Làm cách nào để đảm bảo ứng dụng trong cụm Kubernetes không bị ngừng hoạt động? PodDisruptionBudget và một lần nữa PodDisruptionBudget.
Các cụm được cập nhật định kỳ và các nút được làm trống. Không có gì đứng yên cả, đó là sự thật. Mọi hoạt động triển khai có nhiều phiên bản đều phải bao gồm PDB (PodDisruptionBudget). Nó được tạo trong một tệp yaml đơn giản được áp dụng cho cụm. Vùng phủ sóng của một PDB cụ thể được xác định bởi bộ chọn nhãn.
Lưu ý: Ngân sách PDB chỉ được tính đến khi vi phạm ngân sách có thể khắc phục được (). Trong những tình huống như lỗi phần cứng, PDB sẽ không hoạt động.
Ví dụ PDB:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-a-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: app-a
Hai thông số chính là matchLabels и minAvailable. Tham số đầu tiên chỉ định ứng dụng nào được áp dụng ngân sách. Ví dụ: nếu tôi có các triển khai có nhãn app: app-a и app: app-b, thì PDB này sẽ chỉ áp dụng cho cái đầu tiên.
Thông số minAvailable được tính đến khi làm trống (làm sạch) nút. Ví dụ: trong ví dụ của chúng tôi, trong quá trình làm trống, tất cả các phiên bản đều bị loại bỏ app: app-a, ngoại trừ hai.
Điều này cho phép bạn kiểm soát số lượng phiên bản của ứng dụng sẽ chạy tại bất kỳ thời điểm nào.
Theo dõi tình trạng ứng dụng
Việc giám sát như vậy có thể thực hiện được theo hai cách: sử dụng các bài kiểm tra Sẵn sàng hoặc Sống động.
Thăm dò đầu tiên (sự sẵn sàng) xác định mức độ sẵn sàng tiếp nhận lưu lượng truy cập của container.
Thứ hai (sự sống động) cho biết container có hoạt động tốt hay cần được khởi động lại.
Các cấu hình liên quan chỉ cần được thêm vào yaml để triển khai. Ở đó bạn có thể chỉ định thời gian chờ, thời gian trễ và số lần thử lại. Xem thêm chi tiết về họ .
Thẻ ở khắp mọi nơi
Nhãn là một trong những khái niệm cơ bản trong Kubernetes. Chúng cho phép các đối tượng tự do giao tiếp với nhau cũng như tạo các truy vấn dựa trên nhãn. Trong Kubernetes, bạn thậm chí có thể truy cập ứng dụng khách và xem các sự kiện để tìm các thẻ cụ thể.
Bạn có thể làm hầu hết mọi thứ với thẻ, nhưng một ví dụ điển hình là tạo nhiều môi trường để chạy các chương trình trên cùng một cụm.
Giả sử bạn sử dụng cùng một cụm cho dev и qa. Điều này có nghĩa là bạn có thể có một ứng dụng app-a, đồng thời làm việc trong cả hai môi trường qa и dev. Trong trường hợp này, chúng ta có thể truy cập riêng vào phiên bản ứng dụng trong một môi trường cụ thể bằng cách chỉ định tham số thích hợp environment. Ví dụ, app: app-a и environment: dev cho một môi trường, và app: app-a и environment: qa cho cái thứ hai.
Điều này cho phép bạn truy cập cả hai phiên bản của ứng dụng, chẳng hạn như để tiến hành thử nghiệm đồng thời.
Đặt mọi thứ theo thứ tự
Kubernetes là một hệ thống rất mạnh mẽ, nhưng bất kỳ hệ thống nào cuối cùng cũng có thể bị sa lầy với quá nhiều quy trình. Kubelet chạy tất cả các quy trình và kiểm tra mà bạn chỉ định cũng như của chính nó.
Tất nhiên, một dịch vụ đơn lẻ sẽ không làm chậm hệ thống và Kubernetes được thiết kế để mở rộng quy mô ngay từ đầu. Nhưng nếu thay vì một triệu dịch vụ xuất hiện, kubelet bắt đầu bị sặc.
Nếu vì lý do nào đó bạn xóa một triển khai (vùng chứa, hình ảnh, bất cứ thứ gì), chỉ cần đảm bảo thực hiện dọn dẹp hoàn toàn.
Gặp gỡ đi
Chúng tôi đã lưu lời khuyên chính cuối cùng. Tìm hiểu ngôn ngữ lập trình Go.
Kubernetes được phát triển trên Go, tất cả các tiện ích mở rộng đều được viết bằng Go và thư viện client-go client cũng được hỗ trợ chính thức.
Nó có thể được sử dụng cho những điều khác nhau và thú vị. Ví dụ: để mở rộng hệ thống Kubernetes theo sở thích của bạn. Vì vậy, bạn có thể sử dụng các chương trình của riêng mình để thu thập dữ liệu, triển khai ứng dụng hoặc đơn giản là dọn dẹp các vùng chứa.
Học ngôn ngữ lập trình Go và thành thạo client-go có lẽ là lời khuyên quan trọng nhất bạn có thể đưa ra cho người dùng Kubernetes mới.
Đọc gì khác:
- .
- ?
- .
Nguồn: www.habr.com