🥇Kubernetes 1.16: tổng quan về những cải tiến chính

Hôm nay, thứ Tư, sẽ diễn ra bản phát hành tiếp theo của Kubernetes - 1.16. Theo truyền thống đã phát triển cho blog của chúng tôi, đây là lần kỷ niệm XNUMX năm chúng tôi nói về những thay đổi quan trọng nhất trong phiên bản mới.

Thông tin được sử dụng để chuẩn bị tài liệu này được lấy từ Bảng theo dõi cải tiến Kubernetes, THAY ĐỔI-1.16 và các vấn đề liên quan, yêu cầu kéo và Đề xuất nâng cao Kubernetes (KEP). Vì vậy, chúng ta hãy đi! ..

Điểm giao

Một số lượng lớn các cải tiến thực sự đáng chú ý (ở trạng thái phiên bản alpha) được trình bày bên cạnh các nút cụm K8 (Kubelet).

Đầu tiên, cái gọi là «container phù du» (Vùng chứa phù du), được thiết kế để đơn giản hóa quy trình gỡ lỗi trong nhóm. Cơ chế mới cho phép bạn khởi chạy các vùng chứa đặc biệt bắt đầu trong không gian tên của các nhóm hiện có và tồn tại trong một thời gian ngắn. Mục đích của họ là tương tác với các nhóm và vùng chứa khác để giải quyết mọi vấn đề và gỡ lỗi. Một lệnh mới đã được triển khai cho tính năng này kubectl debug, về bản chất tương tự như kubectl exec: chỉ thay vì chạy một tiến trình trong vùng chứa (như trong exec) nó khởi chạy một container trong một nhóm. Ví dụ: lệnh này sẽ kết nối một vùng chứa mới với một nhóm:

kubectl debug -c debug-shell --image=debian target-pod -- bash

Thông tin chi tiết về các thùng chứa phù du (và ví dụ về việc sử dụng chúng) có thể được tìm thấy trong KEP tương ứng. Việc triển khai hiện tại (trong K8s 1.16) là phiên bản alpha và trong số các tiêu chí để chuyển sang phiên bản beta là “thử nghiệm API Bộ chứa tạm thời cho ít nhất 2 bản phát hành [Kubernetes]”.

NB: Về bản chất và thậm chí cả tên gọi của nó, tính năng này giống với một plugin đã có sẵn gỡ lỗi kubectlvề cái mà chúng tôi đã viết. Người ta hy vọng rằng với sự ra đời của các vùng chứa phù du, việc phát triển một plugin bên ngoài riêng biệt sẽ chấm dứt.

Một sự đổi mới khác - PodOverhead - được thiết kế để cung cấp cơ chế tính toán chi phí chung cho nhóm, có thể thay đổi rất nhiều tùy thuộc vào thời gian chạy được sử dụng. Điển hình là các tác giả KEP này dẫn đến Kata Container, yêu cầu chạy kernel khách, tác nhân kata, hệ thống init, v.v. Khi chi phí chung trở nên quá lớn thì không thể bỏ qua, điều đó có nghĩa là cần phải có cách tính đến nó để đưa ra hạn ngạch, lập kế hoạch, v.v. Để triển khai nó trong PodSpec trường đã thêm Overhead *ResourceList (so sánh với số liệu ở RuntimeClass, nếu một cái được sử dụng).

Một sự đổi mới đáng chú ý khác là quản lý cấu trúc liên kết nút (Trình quản lý cấu trúc liên kết nút), được thiết kế để thống nhất cách tiếp cận tinh chỉnh việc phân bổ tài nguyên phần cứng cho các thành phần khác nhau trong Kubernetes. Sáng kiến này được thúc đẩy bởi nhu cầu ngày càng tăng của các hệ thống hiện đại khác nhau (từ lĩnh vực viễn thông, học máy, dịch vụ tài chính, v.v.) về điện toán song song hiệu suất cao và giảm thiểu độ trễ khi thực hiện các hoạt động, nhờ đó chúng sử dụng CPU và công nghệ tiên tiến. khả năng tăng tốc phần cứng. Những tối ưu hóa như vậy trong Kubernetes cho đến nay đã đạt được nhờ các thành phần khác nhau (Trình quản lý CPU, Trình quản lý thiết bị, CNI) và giờ đây chúng sẽ được thêm một giao diện nội bộ duy nhất giúp thống nhất cách tiếp cận và đơn giản hóa việc kết nối các cấu trúc liên kết tương tự mới - được gọi là cấu trúc liên kết- nhận thức - các thành phần ở phía Kubelet. Chi tiết - trong KEP tương ứng.

Sơ đồ thành phần quản lý cấu trúc liên kết

Tính năng tiếp theo - kiểm tra container trong khi chúng đang chạy (thăm dò khởi động). Như bạn đã biết, đối với những container mất nhiều thời gian khởi chạy, rất khó để có được trạng thái cập nhật: chúng hoặc bị “khai tử” trước khi thực sự bắt đầu hoạt động hoặc chúng rơi vào tình trạng bế tắc trong một thời gian dài. Kiểm tra mới (được kích hoạt thông qua cổng tính năng được gọi là StartupProbeEnabled) hủy - hay đúng hơn là trì hoãn - hiệu lực của bất kỳ kiểm tra nào khác cho đến thời điểm nhóm chạy xong. Vì lý do này, tính năng này ban đầu được gọi là pod-startup liveness-thăm dò chờ đợi. Đối với các nhóm mất nhiều thời gian để bắt đầu, bạn có thể thăm dò trạng thái trong khoảng thời gian tương đối ngắn.

Ngoài ra, cải tiến cho RuntimeClass ngay lập tức có sẵn ở trạng thái beta, bổ sung thêm hỗ trợ cho “các cụm không đồng nhất”. C Lập lịch lớp học thời gian chạy Giờ đây, mỗi nút không cần thiết phải hỗ trợ cho từng RuntimeClass: đối với các nhóm, bạn có thể chọn RuntimeClass mà không cần suy nghĩ về cấu trúc liên kết cụm. Trước đây, để đạt được điều này - để các nhóm kết thúc trên các nút với sự hỗ trợ cho mọi thứ chúng cần - cần phải chỉ định các quy tắc thích hợp cho NodeSelector và dung sai. TRONG MŨ LƯỠI TRAI Nó nói về các ví dụ về việc sử dụng và tất nhiên là cả chi tiết triển khai.

Сеть

Hai tính năng mạng quan trọng xuất hiện lần đầu tiên (ở phiên bản alpha) trong Kubernetes 1.16 là:

Hỗ trợ ngăn xếp mạng kép - IPv4/IPv6 - và “sự hiểu biết” tương ứng của nó ở cấp độ nhóm, nút, dịch vụ. Nó bao gồm khả năng tương tác IPv4-to-IPv4 và IPv6-to-IPv6 giữa các nhóm, từ nhóm đến dịch vụ bên ngoài, triển khai tham chiếu (trong các plugin Bridge CNI, PTP CNI và Host-Local IPAM), cũng như Tương thích ngược với các cụm Kubernetes đang chạy Chỉ IPv4 hoặc IPv6. Chi tiết triển khai có trong MŨ LƯỠI TRAI.
Ví dụ hiển thị địa chỉ IP của 4 loại (IPv6 và IPvXNUMX) trong danh sách pod:
```
kube-master# kubectl get pods -o wide
NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
kube-master#
```
API mới cho điểm cuối - API điểm cuối. Nó giải quyết các vấn đề về hiệu suất/khả năng mở rộng của API điểm cuối hiện có ảnh hưởng đến các thành phần khác nhau trong mặt phẳng điều khiển (apiserver, etcd, bộ điều khiển điểm cuối, kube-proxy). API mới sẽ được thêm vào nhóm Discovery API và có thể phục vụ hàng chục nghìn điểm cuối phụ trợ trên mỗi dịch vụ trong một cụm bao gồm hàng nghìn nút. Để thực hiện việc này, mỗi Dịch vụ được ánh xạ tới N đối tượng EndpointSlice, mỗi điểm theo mặc định có không quá 100 điểm cuối (giá trị có thể định cấu hình được). API EndpointSlice cũng sẽ mang đến cơ hội phát triển trong tương lai: hỗ trợ nhiều địa chỉ IP cho mỗi nhóm, trạng thái mới cho điểm cuối (không chỉ Ready и NotReady), cài đặt phụ động cho điểm cuối.

Phiên bản được trình bày trong bản phát hành trước đã đạt đến phiên bản beta người hoàn thiện, được đặt tên service.kubernetes.io/load-balancer-cleanup và gắn liền với từng dịch vụ với loại LoadBalancer. Tại thời điểm xóa một dịch vụ như vậy, nó sẽ ngăn chặn việc xóa tài nguyên thực sự cho đến khi hoàn tất việc “dọn dẹp” tất cả các tài nguyên cân bằng có liên quan.

Máy API

“Cột mốc ổn định” thực sự nằm ở khu vực máy chủ API Kubernetes và tương tác với nó. Điều này xảy ra phần lớn nhờ vào chuyển sang trạng thái ổn định những người không cần giới thiệu đặc biệt Định nghĩa tài nguyên tùy chỉnh (CRD), đã có trạng thái beta kể từ những ngày xa xôi của Kubernetes 1.7 (và đây là tháng 2017 năm XNUMX!). Sự ổn định tương tự đến với các tính năng liên quan:

"tài nguyên phụ" với /status и /scale cho Tài nguyên tùy chỉnh;
sự biến đổi các phiên bản dành cho CRD, dựa trên webhook bên ngoài;
trình bày gần đây (trong K8s 1.15) giá trị mặc định (mặc định) và loại bỏ trường tự động (cắt tỉa) cho Tài nguyên tùy chỉnh;
cơ hội sử dụng lược đồ OpenAPI v3 để tạo và xuất bản tài liệu OpenAPI dùng để xác thực tài nguyên CRD ở phía máy chủ.

Một cơ chế khác từ lâu đã trở nên quen thuộc với quản trị viên Kubernetes: webhook tuyển sinh - cũng vẫn ở trạng thái beta trong một thời gian dài (kể từ K8s 1.9) và hiện được tuyên bố là ổn định.

Hai tính năng khác đã đạt đến phiên bản beta: áp dụng phía máy chủ и xem dấu trang.

Và sự đổi mới đáng kể duy nhất trong phiên bản alpha là thất bại từ SelfLink - một URI đặc biệt đại diện cho đối tượng được chỉ định và là một phần của ObjectMeta и ListMeta (tức là một phần của bất kỳ đối tượng nào trong Kubernetes). Tại sao họ lại từ bỏ nó? Động lực một cách đơn giản âm thanh vì thiếu những lý do thực sự (quá sức) để lĩnh vực này vẫn tồn tại. Các lý do chính thức hơn là để tối ưu hóa hiệu suất (bằng cách loại bỏ một trường không cần thiết) và để đơn giản hóa công việc của máy chủ chung, buộc phải xử lý trường đó theo cách đặc biệt (đây là trường duy nhất được đặt ngay trước đối tượng được xuất bản nhiều kỳ). Sự lỗi thời thực sự (trong phiên bản beta) SelfLink sẽ xảy ra bởi Kubernetes phiên bản 1.20 và phiên bản cuối cùng - 1.21.

Lưu trữ dữ liệu

Công việc chính trong lĩnh vực lưu trữ, như trong các phiên bản trước, được thực hiện trong khu vực Hỗ trợ CSI. Những thay đổi chính ở đây là:

lần đầu tiên (ở phiên bản alpha) xuất hiện Hỗ trợ plugin CSI cho các nút công nhân Windows: cách làm việc hiện tại với bộ lưu trữ cũng sẽ thay thế các plugin trong cây trong lõi Kubernetes và các plugin FlexVolume của Microsoft dựa trên Powershell;

Lược đồ triển khai các plugin CSI trong Kubernetes cho Windows
cơ hội thay đổi kích thước khối lượng CSI, được giới thiệu trở lại trong K8s 1.12, đã phát triển thành phiên bản beta;
Một "khuyến mãi" tương tự (từ alpha lên beta) đã đạt được nhờ khả năng sử dụng CSI để tạo các khối phù du cục bộ (Hỗ trợ khối lượng nội tuyến CSI).

Được giới thiệu trong phiên bản trước của Kubernetes chức năng nhân bản khối lượng (sử dụng PVC hiện có làm DataSource để tạo PVC mới) hiện cũng đã nhận được trạng thái beta.

Người lập kế hoạch

Hai thay đổi đáng chú ý về việc lập kế hoạch (cả hai đều ở dạng alpha):

EvenPodsSpreading - cơ hội sử dụng nhóm thay vì các đơn vị ứng dụng logic để “phân phối công bằng” tải (như Triển khai và Bộ bản sao) và điều chỉnh phân phối này (dưới dạng yêu cầu cứng hoặc dưới dạng điều kiện mềm, tức là mức độ ưu tiên). Tính năng này sẽ mở rộng khả năng phân phối hiện có của các nhóm được lên kế hoạch, hiện bị giới hạn bởi các tùy chọn PodAffinity и PodAntiAffinity, mang lại cho quản trị viên quyền kiểm soát tốt hơn trong vấn đề này, điều đó có nghĩa là tính sẵn sàng cao hơn và mức tiêu thụ tài nguyên được tối ưu hóa tốt hơn. Chi tiết - trong MŨ LƯỠI TRAI.
Sử dụng Chính sách BestFit в Hàm ưu tiên được yêu cầuToCapacityRatio trong quá trình lập kế hoạch nhóm, điều này sẽ cho phép áp dụng đóng gói thùng (“đóng gói trong vùng chứa”) cho cả tài nguyên cơ bản (bộ xử lý, bộ nhớ) và tài nguyên mở rộng (như GPU). Để biết thêm chi tiết, xem MŨ LƯỠI TRAI.

Lập lịch nhóm: trước khi sử dụng chính sách phù hợp nhất (trực tiếp thông qua bộ lập lịch mặc định) và với việc sử dụng nó (thông qua bộ mở rộng bộ lập lịch)

Ngoài ra, được trình bày khả năng tạo các plugin lập lịch trình của riêng bạn bên ngoài cây phát triển Kubernetes chính (ngoài cây).

Các thay đổi khác

Cũng trong bản phát hành Kubernetes 1.16 có thể lưu ý sáng kiến cho đưa số liệu có sẵn theo thứ tự đầy đủhay chính xác hơn là phù hợp với quy định chính thức đến thiết bị K8s. Họ chủ yếu dựa vào tương ứng Tài liệu Prometheus. Sự không nhất quán nảy sinh vì nhiều lý do (ví dụ: một số chỉ số được tạo đơn giản trước khi hướng dẫn hiện tại xuất hiện) và các nhà phát triển quyết định rằng đã đến lúc đưa mọi thứ về một tiêu chuẩn duy nhất, “phù hợp với phần còn lại của hệ sinh thái Prometheus”. Việc triển khai sáng kiến này hiện đang ở trạng thái alpha, trạng thái này sẽ được nâng cấp dần dần trong các phiên bản tiếp theo của Kubernetes lên phiên bản beta (1.17) và ổn định (1.18).

Ngoài ra, có thể lưu ý những thay đổi sau:

Hỗ trợ phát triển Windows с vẻ bề ngoài Tiện ích Kubeadm cho HĐH này (phiên bản alpha), cơ hội RunAsUserName dành cho vùng chứa Windows (phiên bản alpha), sự cải tiến Tài khoản dịch vụ được quản lý theo nhóm (gMSA) hỗ trợ phiên bản beta, ủng hộ mount/đính kèm cho khối lượng vSphere.
tái chế cơ chế nén dữ liệu trong phản hồi API. Trước đây, bộ lọc HTTP đã được sử dụng cho những mục đích này, điều này áp đặt một số hạn chế khiến bộ lọc này không được bật theo mặc định. "Nén yêu cầu minh bạch" hiện hoạt động: khách hàng gửi Accept-Encoding: gzip trong tiêu đề, chúng sẽ nhận được phản hồi được nén bằng GZIP nếu kích thước của nó vượt quá 128 KB. Máy khách Go tự động hỗ trợ nén (gửi tiêu đề được yêu cầu), vì vậy chúng sẽ ngay lập tức nhận thấy lưu lượng truy cập giảm. (Có thể cần sửa đổi một chút cho các ngôn ngữ khác.)
Đã trở thành có thể chia tỷ lệ HPA từ/đến XNUMX nhóm dựa trên số liệu bên ngoài. Nếu bạn chia tỷ lệ dựa trên các đối tượng/số liệu bên ngoài thì khi khối lượng công việc không hoạt động, bạn có thể tự động chia tỷ lệ thành 0 bản sao để tiết kiệm tài nguyên. Tính năng này đặc biệt hữu ích trong trường hợp nhân viên yêu cầu tài nguyên GPU và số lượng nhân viên nhàn rỗi khác nhau vượt quá số lượng GPU có sẵn.
Khách hàng mới - k8s.io/client-go/metadata.Client - để truy cập “tổng quát” vào các đối tượng. Nó được thiết kế để dễ dàng truy xuất siêu dữ liệu (tức là tiểu mục metadata) từ các tài nguyên của cụm và thực hiện các hoạt động thu gom rác và hạn ngạch với chúng.
Xây dựng Kubernetes bây giờ bạn có thể không có nhà cung cấp đám mây kế thừa (“tích hợp” trong cây) (phiên bản alpha).
Đến tiện ích kubeadm thêm khả năng thử nghiệm (phiên bản alpha) để áp dụng các bản vá tùy chỉnh trong quá trình hoạt động init, join и upgrade. Tìm hiểu thêm về cách sử dụng cờ --experimental-kustomize, nhìn vào MŨ LƯỠI TRAI.
Điểm cuối mới cho apiserver - readyz, - cho phép bạn xuất thông tin về mức độ sẵn sàng của nó. Máy chủ API hiện cũng có cờ --maximum-startup-sequence-duration, cho phép bạn điều chỉnh việc khởi động lại của nó.
Hai tính năng cho Azure tuyên bố ổn định: hỗ trợ vùng sẵn sàng (Vùng sẵn có) và nhóm tài nguyên chéo (R G). Ngoài ra, Azure đã thêm:
- hỗ trợ xác thực AAD và ADFS;
- chú thích service.beta.kubernetes.io/azure-pip-name để chỉ định IP công khai của bộ cân bằng tải;
- cơ hội thiết lập LoadBalancerName и LoadBalancerResourceGroup.
AWS hiện có ủng hộ cho EBS trên Windows và tối ưu hóa Lệnh gọi API EC2 DescribeInstances.
Kubeadm hiện đã độc lập di cư Cấu hình CoreDNS khi nâng cấp phiên bản CoreDNS.
nhị phân vvd trong hình ảnh Docker tương ứng làm xong world-executable, cho phép bạn chạy image này mà không cần quyền root. Ngoài ra, hình ảnh di chuyển etcd dừng lại hỗ trợ phiên bản etcd2.
В Bộ chia tỷ lệ tự động cụm 1.16.0 chuyển sang sử dụng distroless làm hình ảnh cơ sở, cải thiện hiệu suất, bổ sung thêm các nhà cung cấp đám mây mới (DigitalOcean, Magnum, Packet).
Cập nhật trong phần mềm đã sử dụng/phụ thuộc: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Đọc thêm trên blog của chúng tôi:

Nguồn: www.habr.com

Kubernetes 1.16: tổng quan về những cải tiến chính