Kubernetes 1.16: 주요 혁신 개요

오늘, 수요일, 일어난다 Kubernetes의 다음 릴리스 - 1.16. 우리 블로그를 위해 발전해 온 전통에 따르면, 이것은 새 버전의 가장 중요한 변경 사항에 대해 이야기하는 XNUMX주년 기념일입니다.

이 자료를 준비하는 데 사용된 정보는 다음에서 가져왔습니다. Kubernetes 개선 사항 추적 테이블, 변경 로그-1.16 관련 문제, 풀 요청, KEP(Kubernetes Enhancement Proposals) 등이 있습니다. 그럼 가자!..

노드

K8s 클러스터 노드(Kubelet) 측면에는 정말 많은 주목할만한 혁신(알파 버전 상태)이 제공됩니다.

첫째, 소위 «임시 컨테이너» (임시 컨테이너), Pod의 디버깅 프로세스를 단순화하도록 설계되었습니다.. 새로운 메커니즘을 사용하면 기존 포드의 네임스페이스에서 시작하고 짧은 시간 동안 유지되는 특수 컨테이너를 시작할 수 있습니다. 그 목적은 문제를 해결하고 디버그하기 위해 다른 포드 및 컨테이너와 상호 작용하는 것입니다. 이 기능을 위해 새로운 명령이 구현되었습니다. kubectl debug, 본질적으로 유사 kubectl exec: 컨테이너에서 프로세스를 실행하는 대신(예: exec) 포드에서 컨테이너를 시작합니다. 예를 들어 다음 명령은 새 컨테이너를 포드에 연결합니다.

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

임시 컨테이너에 대한 자세한 내용(및 사용 예)은 다음에서 확인할 수 있습니다. 해당 KEP. 현재 구현(K8s 1.16)은 알파 버전이며, 베타 버전으로 전환하기 위한 기준 중 하나는 "[Kubernetes]의 최소 2개 릴리스에 대해 임시 컨테이너 API를 테스트하는 것"입니다.

NB: 본질적으로, 심지어 이름까지, 이 기능은 이미 존재하는 플러그인과 유사합니다. kubectl-디버그우리에 대해 이미 썼다. 임시 컨테이너의 등장으로 별도의 외부 플러그인 개발이 중단될 것으로 예상됩니다.

또 다른 혁신 - PodOverhead - 제공하도록 설계되었습니다. 포드의 간접비를 계산하는 메커니즘, 이는 사용된 런타임에 따라 크게 달라질 수 있습니다. 예를 들어, 저자들은 이 KEP 게스트 커널, kata 에이전트, init 시스템 등을 실행해야 하는 Kata 컨테이너가 생성됩니다. 오버헤드가 너무 커지면 무시할 수 없으므로 추가 할당량, 계획 등을 고려할 수 있는 방법이 필요합니다. 그것을 구현하려면 PodSpec 필드가 추가됨 Overhead *ResourceList (데이터와 비교 RuntimeClass, 하나가 사용되는 경우).

또 다른 주목할만한 혁신은 노드 토폴로지 관리자 (노드 토폴로지 관리자), Kubernetes의 다양한 구성 요소에 대한 하드웨어 리소스 할당을 미세 조정하는 접근 방식을 통합하도록 설계되었습니다. 이 이니셔티브는 고성능 병렬 컴퓨팅을 위한 다양한 최신 시스템(통신, 기계 학습, 금융 서비스 등)에 대한 수요가 증가하고 고급 CPU 및 하드웨어 가속 기능. Kubernetes의 이러한 최적화는 지금까지 서로 다른 구성 요소(CPU 관리자, 장치 관리자, CNI) 덕분에 달성되었으며 이제 접근 방식을 통합하고 새로운 유사한 소위 토폴로지의 연결을 단순화하는 단일 내부 인터페이스가 추가됩니다. 인식 - Kubelet 측의 구성 요소입니다. 세부정보 - 에서 해당 KEP.

토폴로지 관리자 구성 요소 다이어그램

다음 기능 - 실행 중인 컨테이너 확인 (시동 프로브). 아시다시피, 실행하는 데 오랜 시간이 걸리는 컨테이너의 경우 최신 상태를 얻기가 어렵습니다. 컨테이너가 실제로 작동하기 전에 "종료"되거나 오랫동안 교착 상태에 빠지게 됩니다. 새로운 검사(라는 기능 게이트를 통해 활성화됨) StartupProbeEnabled)는 Pod 실행이 완료될 때까지 다른 검사의 효과를 취소하거나 연기합니다. 이러한 이유로 이 기능은 원래 호출되었습니다. 포드 시작 활성도 프로브 홀드오프. 시작하는 데 오랜 시간이 걸리는 포드의 경우 상대적으로 짧은 시간 간격으로 상태를 폴링할 수 있습니다.

또한 RuntimeClass의 개선 사항은 베타 상태에서 즉시 사용할 수 있으며 "이기종 클러스터"에 대한 지원이 추가됩니다. 씨 런타임클래스 스케줄링 이제 각 노드가 각 RuntimeClass를 지원할 필요가 전혀 없습니다. 포드의 경우 클러스터 토폴로지에 대해 생각하지 않고 RuntimeClass를 선택할 수 있습니다. 이전에는 이를 달성하기 위해(Pod가 필요한 모든 것을 지원하는 노드에 있도록) NodeSelector 및 허용에 적절한 규칙을 할당해야 했습니다. 안에 KEP 사용 예와 구현 세부 사항에 대해 설명합니다.

네트워크

Kubernetes 1.16에서 처음으로(알파 버전) 등장한 두 가지 중요한 네트워킹 기능은 다음과 같습니다.

• 지원 이중 네트워크 스택 - IPv4/IPv6 - 그리고 포드, 노드, 서비스 수준에서의 해당 "이해". 여기에는 포드에서 외부 서비스까지, 참조 구현(Bridge CNI, PTP CNI 및 호스트-로컬 IPAM 플러그인 내)뿐만 아니라 실행 중인 Kubernetes 클러스터와 역호환되는 포드 간 IPv4-IPv4 및 IPv6-IPv6 상호 운용성이 포함됩니다. IPv4 또는 IPv6만 해당. 구현 세부 사항은 KEP.

  포드 목록에 두 가지 유형(IPv4 및 IPv6)의 IP 주소를 표시하는 예:

  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 - 엔드포인트슬라이스 API. 컨트롤 플레인의 다양한 구성 요소(apiserver, etcd, Endpoints-controller, kube-proxy)에 영향을 미치는 기존 Endpoint API의 성능/확장성 문제를 해결합니다. 새로운 API는 Discovery API 그룹에 추가되며 수천 개의 노드로 구성된 클러스터의 각 서비스에서 수만 개의 백엔드 엔드포인트를 제공할 수 있습니다. 이를 위해 각 서비스는 N개 개체에 매핑됩니다. EndpointSlice, 각각에는 기본적으로 100개 이하의 엔드포인트가 있습니다(값은 구성 가능). EndpointSlice API는 향후 개발을 위한 기회도 제공합니다. 즉, 각 포드에 대한 여러 IP 주소 지원, 엔드포인트에 대한 새로운 상태(뿐만 아니라 Ready и NotReady), 엔드포인트에 대한 동적 하위 설정.

지난번 릴리즈에서 선보인 것이 베타 버전에 이르렀습니다. 종료 자, 명명 된 service.kubernetes.io/load-balancer-cleanup 유형으로 각 서비스에 첨부됩니다. LoadBalancer. 이러한 서비스를 삭제할 때 모든 관련 밸런서 리소스의 "정리"가 완료될 때까지 리소스의 실제 삭제를 방지합니다.

API 기계

실제 "안정화 이정표"는 Kubernetes API 서버 및 서버와의 상호 작용 영역에 있습니다. 이런 일은 주로 다음과 같은 덕분에 일어났습니다. 특별한 소개가 필요하지 않은 사람들을 안정적인 상태로 전환 사용자 정의 리소스 정의 (CRD), 이는 Kubernetes 1.7이 나온 먼 시절부터 베타 상태였습니다(그리고 지금은 2017년 XNUMX월입니다!). 관련 기능에도 동일한 안정화가 이루어졌습니다.

• "하위 리소스" 과 /status и /scale CustomResources의 경우;
• 변형 외부 웹훅을 기반으로 하는 CRD 버전;
• 최근에 발표 (K8s 1.15에서) 기본값 (기본값) 및 자동 필드 제거 (전정) CustomResources의 경우;
• 기회 OpenAPI v3 스키마를 사용하여 서버 측에서 CRD 리소스의 유효성을 검사하는 데 사용되는 OpenAPI 문서를 생성하고 게시합니다.

Kubernetes 관리자에게 오랫동안 익숙해진 또 다른 메커니즘은 다음과 같습니다. 입장 웹훅 - 또한 오랫동안(K8s 1.9 이후) 베타 상태로 유지되었으며 현재는 안정적으로 선언되었습니다.

다른 두 가지 기능이 베타 버전에 도달했습니다. 서버 측 적용 и 북마크 보기.

그리고 알파 버전에서 유일하게 중요한 혁신은 실패 부터 SelfLink — 지정된 객체를 나타내고 다음의 일부인 특수 URI ObjectMeta и ListMeta (즉, Kubernetes에 있는 모든 객체의 일부). 왜 그들은 그것을 버리고 있습니까? 간단한 방법으로 동기 부여 소리 이 분야가 여전히 존재해야 하는 실질적인(압도적인) 이유가 없기 때문입니다. 보다 공식적인 이유는 (불필요한 필드를 제거하여) 성능을 최적화하고 이러한 필드를 특별한 방법으로 처리해야 하는 generic-apiserver의 작업을 단순화하기 위한 것입니다(이것은 객체 바로 앞에 설정되는 유일한 필드입니다). 직렬화되어 있습니다). 실제 노후화(베타 내) SelfLink Kubernetes 버전 1.20 및 최종 버전 1.21에서 발생합니다.

데이터 저장

이전 릴리스와 마찬가지로 저장 영역의 주요 작업은 해당 영역에서 관찰됩니다. CSI 지원. 주요 변경 사항은 다음과 같습니다.

• 처음으로 (알파 버전) 출연 한 Windows 작업자 노드에 대한 CSI 플러그인 지원: 현재 스토리지 작업 방식은 Kubernetes 코어의 트리 내 플러그인과 Powershell 기반 Microsoft의 FlexVolume 플러그인도 대체합니다.

  
  Windows용 Kubernetes에서 CSI 플러그인을 구현하기 위한 체계

• 기회 CSI 볼륨 크기 조정K8s 1.12에서 다시 소개된 은 베타 버전으로 성장했습니다.
• 유사한 "승격"(알파에서 베타로)은 CSI를 사용하여 로컬 임시 볼륨을 생성하는 기능을 통해 달성되었습니다(CSI 인라인 볼륨 지원).

이전 버전의 Kubernetes에서 도입됨 볼륨 복제 기능 (기존 PVC를 DataSource 새로운 PVC를 생성하기 위해)도 이제 베타 상태를 받았습니다.

스케줄러

예약에 대한 두 가지 주목할만한 변경 사항(둘 다 알파 버전):

• EvenPodsSpreading - 기회 로드의 "공정한 분배"를 위해 논리적 애플리케이션 장치 대신 포드를 사용하십시오. (예: 배포 및 ReplicaSet) 및 이 배포를 조정합니다(하드 요구 사항 또는 소프트 조건, 즉 우선 순위). 이 기능은 현재 옵션으로 제한되어 있는 계획된 포드의 기존 배포 기능을 확장합니다. PodAffinity и PodAntiAffinity, 관리자가 이 문제에 대해 더 세밀하게 제어할 수 있게 되므로 고가용성이 향상되고 리소스 소비가 최적화됩니다. 세부정보 - 에서 KEP.
• 사용 베스트핏 정책 в RequestedToCapacityRatio 우선순위 함수 포드 계획 중에 적용하다 빈 포장 기본 리소스(프로세서, 메모리)와 확장 리소스(예: GPU) 모두에 대한 (“컨테이너에 포장”). 자세한 내용은 다음을 참조하세요. KEP.

  
  Pod 예약: 최적 정책을 사용하기 전(기본 스케줄러를 통해 직접) 및 사용 시(스케줄러 확장기를 통해)

또한, 제시 기본 Kubernetes 개발 트리 외부(트리 외부)에서 자체 스케줄러 플러그인을 생성하는 기능.

기타 변경 사항

또한 Kubernetes 1.16 릴리스에서는 다음과 같은 점에 유의할 수 있습니다. 에 대한 이니셔티브 가져오는 전체 순서로 사용 가능한 측정항목, 또는 더 정확하게는 공식 규정 K8s 계측에. 그들은 해당 항목에 크게 의존합니다. 프로메테우스 문서. 다양한 이유로 불일치가 발생했으며(예를 들어 일부 측정항목은 현재 지침이 나타나기 전에 단순히 생성되었습니다.) 개발자는 이제 모든 것을 "나머지 Prometheus 생태계에 맞춰" 단일 표준으로 가져갈 때라고 결정했습니다. 이 이니셔티브의 현재 구현은 알파 상태이며, Kubernetes의 후속 버전에서 베타(1.17) 및 안정 버전(1.18)으로 점진적으로 승격될 예정입니다.

또한 다음과 같은 변경 사항을 확인할 수 있습니다.

• Windows 지원 개발 с 모습 이 OS(알파 버전)용 Kubeadm 유틸리티, 기회 RunAsUserName Windows 컨테이너(알파 버전)의 경우 개선 그룹 관리 서비스 계정(gMSA)은 베타 버전까지 지원됩니다. 지원하다 vSphere 볼륨에 대한 마운트/연결.
• 재활용 API 응답의 데이터 압축 메커니즘. 이전에는 이러한 목적으로 HTTP 필터가 사용되었으므로 기본적으로 활성화되지 못하게 하는 여러 가지 제한 사항이 적용되었습니다. 이제 "투명한 요청 압축"이 작동합니다. 클라이언트가 전송합니다. Accept-Encoding: gzip 헤더에서 크기가 128KB를 초과하면 GZIP 압축 응답을 받습니다. Go 클라이언트는 자동으로 압축(필수 헤더 전송)을 지원하므로 트래픽 감소를 즉시 확인할 수 있습니다. (다른 언어의 경우 약간의 수정이 필요할 수 있습니다.)
• 가능해졌습니다 외부 지표를 기반으로 HPA를 XNUMX 포드에서/XNUMX 포드로 확장. 개체/외부 지표를 기준으로 확장하는 경우 워크로드가 유휴 상태일 때 자동으로 복제본을 0개로 확장하여 리소스를 절약할 수 있습니다. 이 기능은 작업자가 GPU 리소스를 요청하고 다양한 유형의 유휴 작업자 수가 사용 가능한 GPU 수를 초과하는 경우에 특히 유용합니다.
• 신규 고객 - k8s.io/client-go/metadata.Client — 객체에 대한 "일반화된" 액세스를 위해. 메타데이터(예: 하위 섹션)를 쉽게 검색하도록 설계되었습니다. metadata)을 클러스터 리소스에서 가져와 가비지 수집 및 할당량 작업을 수행합니다.
• 쿠버네티스 구축 이제 너는 할 수있어. 레거시(트리에 "내장") 클라우드 공급자가 없습니다(알파 버전).
• kubeadm 유틸리티로 추가 작업 중에 사용자 정의 패치를 적용하는 실험적(알파 버전) 기능 init, join и upgrade. 플래그 사용 방법에 대해 자세히 알아보세요. --experimental-kustomize, 을 참조하십시오 KEP.
• apiserver의 새로운 엔드포인트 - readyz, - 준비 상태에 대한 정보를 내보낼 수 있습니다. API 서버에도 이제 플래그가 있습니다. --maximum-startup-sequence-duration, 다시 시작을 조절할 수 있습니다.
• 두 Azure의 기능 안정 선언: 지원 가용성 영역 (가용성 영역) 및 교차 리소스 그룹 (RG). 또한 Azure에는 다음이 추가되었습니다.
  • 인증 지원 AAD 및 ADFS;
  • 주석 service.beta.kubernetes.io/azure-pip-name 로드 밸런서의 공용 IP를 지정합니다.
  • 기회 настройки LoadBalancerName и LoadBalancerResourceGroup.
• AWS는 이제 지원 Windows의 EBS용 및 최적화된 EC2 API 호출 DescribeInstances.
• Kubeadm은 이제 독립되었습니다 마이그레이션 CoreDNS 버전 업그레이드 시 CoreDNS 구성.
• 바이너리 등 해당 Docker 이미지에서 끝냈다. world-executable을 사용하면 루트 권한 없이 이 이미지를 실행할 수 있습니다. 또한 etcd 마이그레이션 이미지 중지 된 etcd2 버전 지원.
• В 클러스터 자동 확장 처리 1.16.0 distroless를 기본 이미지로 사용하도록 전환하고 성능을 개선했으며 새로운 클라우드 공급자(DigitalOcean, Magnum, Packet)를 추가했습니다.
• 사용/종속 소프트웨어 업데이트: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

블로그에서도 읽어보세요.

• «Kubernetes 1.15: 주요 혁신 개요";
• «Kubernetes 1.14: 주요 혁신 개요";
• «Kubernetes 1.13: 주요 혁신 개요";
• «Kubernetes 1.12: 주요 혁신 개요".

출처 : habr.com