Đêm này bản phát hành tiếp theo của Kubernetes - . Theo truyền thống đã phát triển cho blog của chúng tôi, chúng tôi đang nói về những thay đổi chính trong phiên bản mới của sản phẩm Nguồn mở tuyệt vời này.
Thông tin được sử dụng để chuẩn bị tài liệu này được lấy từ , và các vấn đề liên quan, yêu cầu kéo, Đề xuất nâng cao Kubernetes (KEP).
Hãy bắt đầu với phần giới thiệu quan trọng về vòng đời của cụm SIG: cụm chuyển đổi dự phòng động Kubernetes (hay chính xác hơn là triển khai HA tự lưu trữ) hiện đang sử dụng các lệnh quen thuộc (trong bối cảnh cụm nút đơn) kubeadm (init и join). Nói tóm lại, đối với điều này:
- các chứng chỉ được cụm sử dụng được chuyển sang bí mật;
- về khả năng sử dụng cụm etcd bên trong cụm K8s (tức là loại bỏ sự phụ thuộc bên ngoài hiện có trước đó) ;
- Ghi lại các cài đặt được đề xuất cho bộ cân bằng tải bên ngoài cung cấp cấu hình có khả năng chịu lỗi (trong tương lai dự kiến sẽ loại bỏ sự phụ thuộc này, nhưng chưa phải ở giai đoạn này).
Kiến trúc của cụm Kubernetes HA được tạo bằng kubeadm
Chi tiết về việc thực hiện có thể được tìm thấy trong . Tính năng này thực sự đã được chờ đợi từ lâu: phiên bản alpha dự kiến sẽ có trong K8s 1.9 nhưng hiện tại mới xuất hiện.
API
Đội apply và nói chung quản lý đối tượng khai báo của kubectl trong apiserver. Bản thân các nhà phát triển đã giải thích ngắn gọn về quyết định của họ bằng cách nói rằng kubectl apply - Tuy nhiên, một phần cơ bản khi làm việc với các cấu hình trong Kubernetes, “nó chứa đầy lỗi và khó sửa”, và do đó chức năng này cần được đưa trở lại bình thường và chuyển sang mặt phẳng điều khiển. Ví dụ đơn giản và rõ ràng về các vấn đề tồn tại ngày nay:
Chi tiết về việc thực hiện có trong . Mức độ sẵn sàng hiện tại là alpha (việc thăng cấp lên phiên bản beta được lên kế hoạch cho bản phát hành Kubernetes tiếp theo).
Có sẵn ở phiên bản alpha sử dụng sơ đồ OpenAPI v3 cho tạo và xuất bản tài liệu OpenAPI cho CustomResources (CR) được sử dụng để xác thực tài nguyên do người dùng xác định của K8 (phía máy chủ) (CustomResourceDefinition, CRD). Xuất bản OpenAPI cho CRD cho phép khách hàng (ví dụ: kubectl) thực hiện xác nhận về phía bạn (trong vòng kubectl create и kubectl apply) và ban hành hồ sơ theo đề án (kubectl explain). Chi tiết - trong .
Nhật ký có sẵn với cờ O_APPEND (nhưng không O_TRUNC) để tránh mất nhật ký trong một số trường hợp và để thuận tiện cho việc cắt bớt nhật ký bằng các tiện ích bên ngoài để xoay.
Cũng trong bối cảnh của API Kubernetes, có thể lưu ý rằng trong PodSandbox и PodSandboxStatus trường runtime_handler để ghi lại thông tin về RuntimeClass trong nhóm (đọc thêm về nó trong văn bản về , trong đó lớp này xuất hiện dưới dạng phiên bản alpha) và trong Webhooks tuyển sinh khả năng xác định phiên bản nào AdmissionReview họ hỗ trợ. Cuối cùng, các quy tắc Webhooks tuyển sinh hiện đã được mức độ sử dụng của chúng bởi các không gian tên và khung cụm.
hầm
, có trạng thái beta kể từ khi phát hành , ổn định (GA): cổng tính năng này không còn bị tắt và sẽ bị xóa trong Kubernetes 1.17.
sử dụng các biến môi trường được gọi là (ví dụ: tên nhóm) cho tên của các thư mục được gắn dưới dạng , được phát triển - dưới dạng một lĩnh vực mới subPathExpr, hiện được sử dụng để xác định tên thư mục mong muốn. Tính năng này ban đầu xuất hiện trong Kubernetes 1.11, nhưng đối với 1.14, nó vẫn ở trạng thái phiên bản alpha.
Giống như bản phát hành Kubernetes trước đó, nhiều thay đổi quan trọng được đưa ra cho CSI (Giao diện lưu trữ vùng chứa) đang phát triển tích cực:
CSI
Đã có sẵn (như một phần của phiên bản alpha) thay đổi kích thước cho khối lượng CSI. Để sử dụng nó, bạn sẽ cần kích hoạt cổng tính năng có tên ExpandCSIVolumes, cũng như sự hiện diện của hỗ trợ cho hoạt động này trong trình điều khiển CSI cụ thể.
Một tính năng khác cho CSI trong phiên bản alpha - tham chiếu trực tiếp (tức là không sử dụng PV/PVC) đến các khối CSI trong thông số kỹ thuật của nhóm. Cái này loại bỏ hạn chế về việc sử dụng CSI làm nơi lưu trữ dữ liệu từ xa độc quyền, mở ra cánh cửa thế giới cho họ . Để sử dụng () phải được kích hoạt CSIInlineVolume cổng tính năng.
Cũng đã có những tiến bộ trong “nội bộ” của Kubernetes liên quan đến CSI, mà người dùng cuối (quản trị viên hệ thống) không thể nhìn thấy ... Hiện tại, các nhà phát triển buộc phải hỗ trợ hai phiên bản của mỗi plugin lưu trữ: một - “trong cách cũ”, bên trong cơ sở mã K8 (trong -tree) và cơ sở thứ hai - như một phần của CSI mới (đọc thêm về nó, ví dụ, trong ). Điều này gây ra những bất tiện dễ hiểu cần được giải quyết khi bản thân CSI ổn định. Không thể đơn giản ngừng sử dụng API của các plugin nội bộ (trong cây) do .
Tất cả điều này dẫn đến thực tế là phiên bản alpha đã đạt mã plugin nội bộ, được triển khai dưới dạng in-tree, trong các plugin CSI, nhờ đó, nỗi lo của các nhà phát triển sẽ giảm bớt khi hỗ trợ một phiên bản plugin của họ và khả năng tương thích với các API cũ sẽ vẫn còn và chúng có thể bị tuyên bố là lỗi thời trong trường hợp thông thường. Dự kiến, trong phiên bản tiếp theo của Kubernetes (1.15), tất cả các plugin của nhà cung cấp đám mây sẽ được di chuyển, việc triển khai sẽ nhận được trạng thái beta và sẽ được kích hoạt trong bản cài đặt K8 theo mặc định. Để biết chi tiết, xem . Sự di cư này cũng dẫn đến từ giới hạn âm lượng được xác định bởi các nhà cung cấp đám mây cụ thể (AWS, Azure, GCE, Cinder).
Ngoài ra, hỗ trợ cho các thiết bị khối có CSI (CSIBlockVolume) lên phiên bản beta.
Nút/Kubelet
Phiên bản Alpha được giới thiệu trong Kubelet, được thiết kế cho trả lại số liệu về các tài nguyên chính. Nói chung, nếu trước đây Kubelet nhận được số liệu thống kê về việc sử dụng vùng chứa từ cAdvisor thì giờ đây, dữ liệu này đến từ môi trường thời gian chạy vùng chứa thông qua CRI (Giao diện thời gian chạy vùng chứa), nhưng khả năng tương thích để làm việc với các phiên bản Docker cũ hơn cũng được giữ nguyên. Trước đây, số liệu thống kê được thu thập trong Kubelet được gửi qua API REST, nhưng giờ đây, điểm cuối được đặt tại /metrics/resource/v1alpha1. Chiến lược dài hạn của nhà phát triển là giảm thiểu bộ số liệu do Kubelet cung cấp. Nhân tiện, bản thân những số liệu này không phải là “số liệu cốt lõi” mà là “số liệu tài nguyên” và được mô tả là “tài nguyên hạng nhất, chẳng hạn như CPU và bộ nhớ”.
Một sắc thái rất thú vị: mặc dù điểm cuối gRPC có lợi thế về hiệu suất rõ ràng so với các trường hợp sử dụng định dạng Prometheus khác nhau (xem kết quả của một trong những điểm chuẩn bên dưới), các tác giả ưa thích định dạng văn bản của Prometheus do sự lãnh đạo rõ ràng của hệ thống giám sát này trong cộng đồng.
“gRPC không tương thích với các hệ thống giám sát chính. Điểm cuối sẽ chỉ hữu ích trong việc phân phối số liệu đến Máy chủ số liệu hoặc giám sát các thành phần tích hợp trực tiếp với nó. Hiệu suất định dạng văn bản Prometheus khi sử dụng bộ nhớ đệm trong Metrics Server đủ tốt để chúng tôi thích Prometheus hơn gRPC do Prometheus được áp dụng rộng rãi trong cộng đồng. Khi định dạng OpenMetrics trở nên ổn định hơn, chúng tôi sẽ có thể đạt được hiệu suất gRPC bằng định dạng dựa trên proto.”
Một trong những thử nghiệm so sánh hiệu suất khi sử dụng định dạng gRPC và Prometheus trong điểm cuối Kubelet mới cho các chỉ số. Nhiều đồ thị và chi tiết khác có thể được tìm thấy trong .
Trong số những thay đổi khác:
- Kubelet bây giờ (một lần) container ở trạng thái không xác định trước khi khởi động lại và xóa các hoạt động.
- Khi sử dụng bây giờ đến vùng chứa init thông tin tương tự như đối với một container thông thường.
- kubelet
usageNanoCorestừ nhà cung cấp số liệu thống kê CRI cũng như cho các nút và vùng chứa trên Windows thống kê mạng. - Thông tin về hệ điều hành và kiến trúc hiện được ghi vào nhãn
kubernetes.io/osиkubernetes.io/archĐối tượng nút (được chuyển từ beta sang GA). - Khả năng chỉ định một nhóm người dùng hệ thống cụ thể cho các vùng chứa trong nhóm (
RunAsGroup, xuất hiện trong ) trước phiên bản beta (được bật theo mặc định). - du và find được sử dụng trong cAdvisor, về triển khai Go.
CLI
Trong cli-runtime và kubectl -k cờ để tích hợp với (nhân tiện, quá trình phát triển nó hiện được thực hiện trong một kho lưu trữ riêng), tức là. để xử lý các tệp YAML bổ sung từ các thư mục tùy chỉnh đặc biệt (để biết chi tiết về cách sử dụng chúng, hãy xem ):
Ví dụ về cách sử dụng tập tin đơn giản (có thể áp dụng tùy chỉnh phức tạp hơn trong )
Ngoài ra:
- đội mới
kubectl create cronjob, cái tên đã nói lên điều đó. - В
kubectl logsbây giờ bạn có thể cờ-f(--followđể phát trực tuyến nhật ký) và-l(--selectorcho truy vấn nhãn). - kubectl sao chép các tập tin được chọn bằng thẻ đại diện.
- Gửi đội
kubectl waitcờ--allđể chọn tất cả các tài nguyên trong không gian tên của loại tài nguyên đã chỉ định.
Những người khác
Các khả năng sau đã nhận được trạng thái ổn định (GA):
- , được sử dụng trong đặc tả nhóm để xác định các điều kiện bổ sung được tính đến ở mức độ sẵn sàng của nhóm;
- Hỗ trợ các trang lớn (cổng tính năng được gọi là );
- ;
- API lớp ưu tiên .
Những thay đổi khác được giới thiệu trong Kubernetes 1.14:
- Chính sách RBAC mặc định không còn cho phép truy cập API
discoveryиaccess-reviewngười dùng không có xác thực (không được xác thực). - Hỗ trợ CoreDNS chính thức Chỉ dành cho Linux, vì vậy khi sử dụng kubeadm để triển khai nó (CoreDNS) trong một cụm, các nút chỉ được chạy trên Linux (nodeSelectors được sử dụng cho hạn chế này).
- Cấu hình CoreDNS mặc định hiện nay thay vì proxy. Ngoài ra, trong CoreDNS sẵn sàngProbe, ngăn cản việc cân bằng tải trên các nhóm thích hợp (chưa sẵn sàng cho dịch vụ).
- Trong kubeadm, trên các giai đoạn
inithoặcupload-certs, tải các chứng chỉ cần thiết để kết nối mặt phẳng điều khiển mới với bí mật kubeadm-certs (sử dụng cờ--experimental-upload-certs). - Phiên bản alpha đã xuất hiện để cài đặt Windows gMSA (Tài khoản dịch vụ được quản lý theo nhóm) - các tài khoản đặc biệt trong Active Directory cũng có thể được các vùng chứa sử dụng.
- Đối với G.C.E. Mã hóa mTLS giữa etcd và kube-apiserver.
- Các bản cập nhật trong phần mềm đã sử dụng/phụ thuộc: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, hỗ trợ Docker 18.09 trong kubeadm và phiên bản API Docker được hỗ trợ tối thiểu hiện là 1.26.
PS
Đọc thêm trên blog của chúng tôi:
- «»;
- «»;
- «»;
- «'.
Nguồn: www.habr.com