K8S 클러스터 만 규모에 도착했을 때, 알리바바에서는 시스템 성능 문제의 다양한 구성 요소를 해결하기 위해?

저자 | 알리 클라우드 플랫폼 컨테이너 수석 기술 전문가 (영으로) Cengfan 노래

이 논문은 대량 생산 환경에서 알리바바 착륙는 Kubernetes의 프로세스는 클러스터 크기에 발생하는 일반적인 문제와 대응하는 솔루션, 컨텐츠 여러 성능과 etcd의 안정성, KUBE-apiserver의 KUBE-컨트롤러를 포함 설명 강화, 이러한 주요 개선는 Kubernetes 내부 알리바바 완 클러스터 노드가 2019에 부드러운 키 살쾡이 (618) 승진을 지원할 수 있습니다.

배경

알리바바 최초의 AI 시스템 (2013)의 시작에서, 클러스터 관리 시스템은 2018 년 포괄적 인 애플리케이션는 Kubernetes의 아키텍처 진화 라운드를 마쳤습니다,이 기간의 이야기가 매우 흥미 롭다, 기회는 혼자하는 당신에게 공유를 제공하기 위해 . 여기에 시스템의 진화의 과정을 무시 아니라 지역 사회와 회사 내에서 포괄적 인 승리는 Kubernetes 이유를 설명 할 수 있지만, 문제의 종류는 애플리케이션는 Kubernetes에서 발생하는 것에 관심의 초점이 될 것입니다, 우리는 중요한 것을 최적화를 할.

알리바바의 생산 환경, 수백만의 전체 네트워크의 수준에서 응용 프로그램의 컨테이너 더 10K보다 용기, 수백 개의 호스트에서 실행 단위의 수천. 알리바바의 핵심 전력 사업 지원 서비스는 수십, 수만 수천 개의 노드의 가장 큰 클러스터를 클러스터. 규모면에서는 Kubernetes 착륙하는 과정에서 대형 규모의 생산 수준에 적용는 Kubernetes하는 방법으로 도전을 많이 직면했다.

로마가 클러스터에서 10,000 노드로 추정는 Kubernetes, 우리는 클러스터 알리의 생산 상태를 결합 바틀 넥 성능을 이해하기 위해, 하루에 내장되지 않은, 규모에 도달 할 것으로 예상된다 :

• 20w 포드
• 100w 객체

우리는 용기를 통해 대규모 클러스터 기반 Kubemark 시뮬레이션 플랫폼, 시동 모드 이상 (50) Kubemark 프로세스를 구축, 컨테이너 (200 개) 4C 시뮬레이션 kubelet이 10k 노드를 사용합니다. 당신이 일반적인 부하 시뮬레이션 클러스터를 실행하면, 우리는 일정 지연 포드와 같은 몇 가지 기본 작업을 찾으 무려 10 초 매우 불안정한 상태에서이 수준 및 클러스터에 도달 매우 높다.

는 Kubernetes 노드 클러스터가 10K에 도달하면 시스템의 다양한 구성 요소는 다음과 같은 해당 성능 문제를 가지고 :

1. etcd 읽기 다수 발생하고 지연을 쓰기 때문에는 Kubernetes 저장된 다수의 객체를 수행 할 수없는 동시에 공간 제한으로 서비스 거부의 상황을 만들고;
2. API 서버 쿼리 포드 / 노드 지연이 매우 높은, 동시 쿼리는 백 엔드 etcd 움을 해결 할 수있다;
3. 컨트롤러, 최신 변경 사항에 대한 API 서버에서 시간에 더 높은 지연 처리를 인식 할 수 없습니다 예외가 다시 시작, 복구 시간 서비스가 몇 분 정도 걸립니다 발생하는 경우;
4. 없는 스케줄러 높은 지연, 낮은 처리량, 알리 사업 매일 운영 및 유지 보수 요구에 적응하지만, 극단적 인 장면 승진 상태를 지원할 수 없습니다.

etcd 개선

이러한 문제를 해결하기 위해, 모든면에서 알리 클라우드 컨테이너 플랫폼은 대규모는 Kubernetes 현장에서 성능을 개선하기 위해 많은 노력을했다.

먼저 etcd 수준, 데이터베이스는 Kubernetes 저장소 개체로, 그 영향이는 Kubernetes 클러스터의 성능에 매우 중요합니다.

• 개선의 첫 번째 버전은, 우리는 데이터 테어 클러스터를 덤프하여 etcd etcd 저장된 데이터의 양을 증가시킬 것이다. 그러나이 방법은 큰 단점은 추가 테어 클러스터, 큰 도전은 운영 및 데이터 보안 클러스터의 유지 관리의 복잡성을 증가이다 가지고 있지만, 데이터 모델의 일관성은 뗏목 복제 그룹, 희생을 기반으로하지 않습니다 데이터의 보안을 제공합니다.

• 개선의 두 번째 버전은, 우리는 개체의 다른 유형에 의해 다른 etcd 클러스터 API 서버를 저장합니다. 안쪽에서 보면 Etcd, 그것은 다른 데이터 디렉토리에 대응하여 하나의 클러스터에 저장된 데이터의 양을 줄이고, 다른 백엔드 etcd에 다른 디렉토리로 라우팅 데이터는 확장 성을 개선 etcd.

• 개선의 세 번째 버전, 우리는 알고리즘의 분산 etcd 페이지 페이지 bbolt의 DB 바닥의 확장에 영향을 미치는 주요 문제를 내부 원칙 etcd의 실현으로 탐구하고 발견 etcd 성장에 저장된 데이터의 양, bbolt로 성능이 크게 감소의 데시벨 선형 검색 "N 연속 메모리 페이지의 페이지 길이"이다.

이 문제를 해결하기 위해, 우리는 segregrated 해시 맵의, 해시 맵 연속 페이지 크기는 시작 페이지 ID 값으로 키, 연속 페이지입니다 기반의 무료 페이지 관리 알고리즘을 설계했습니다. 성능을 크게 향상 segregrated 해시 맵의 아이들을 찾기 위해 검사를 통해이 페이지를 O (1)을 얻을 수 있습니다. 블록의 릴리스에 따라, 새로운 알고리즘을 시도하고 주소 인접한 페이지를 병합하고, 업데이트는 해시 맵을 segregrated합니다. 알고리즘의 자세한 분석은 보웬 블로그를 볼 수 있습니다 CNCF에 발표되었다 :

https://www.cncf.io/blog/2019/05/09/performance-optimization-of-etcd-in-web-scale-data-scenario/

이 개선 된 알고리즘을 통해, 우리는 크게 스케일 etcd 저장된 데이터를 향상 1백기가바이트, 추천 2기가바이트에서 확장 된 저장 공간을 etcd 수 있고, 읽고 상당한 지연 증가없이 작성. 또한, 우리는 또한 협력과 구글 엔지니어들은 etcd 뗏목 학습자 (사육사의 관찰자 등) / 완전 동시 읽기 및 기타 기능, 강화 된 보안을 개발하고 읽기에 대한 성능 데이터를 쓸 수있다. 이러한 개선은 오픈 소스 커뮤니티 버전이 etcd 3.4 출시 예정 기여했다.

API 서버 개선

효율적인 노드 하트 비트

는 Kubernetes 클러스터에서의 영향이 큰 핵심 문제로 확산되고 효과적으로 하트 비트 노드 처리하는 방법입니다. 일반적인 제조 환경 (비 trival)에서 kubelet 10S 모든 심장 박동을보고, 각각의 하트 비트 요청의 내용은 두 가져올 15킬로바이트 (수십 미터 미러 노드를 포함하고, 볼륨 정보를 복수)에 도달 큰 문제 :

1. 하트 비트 요청이 etcd 클러스터의 10,000 노드에서 노드 객체를 업데이트 트리거, 트랜잭션을 생성합니다 이러한 업데이트는 (변경 내역을 기록합니다 etcd)의 거의 1기가바이트 / 분을 기록;
2. API 서버 높은 CPU 소비, 노드 노드는 매우 큰, CPU 오버 헤드 하트 비트 요청의 직렬화 / 역 직렬화 오버 헤드가 큰 거래는 80 %까지 점유 API 서버 CPU 시간을 초과한다.

이러한 문제를 해결하기 위하여는 Kubernetes 새로운 도입 build-in Lease API 밀접 즉, 화상 위 노드 오브젝트로부터 분사 정보 박동 관련 Lease . 원래 한 번 대상 노드로 업그레이드 매 10 초마다 업데이트 kubelet :

1. 각리스 10S 업데이트 목적은 살아남은 오브젝트가리스의 상태에 따른 것인지 결정하기 위해 노드에 노드 컨트롤러의 가능한 상태를 보였다;
2. 호환성을 고려하여, 한 번씩 60 업데이트 대상 노드가 같은 Eviction_ _Manager이 등이 원래의 논리 연산을 따라 계속 감소되었습니다.

때문에 Lease 물체가 아주 작은, 그래서 업데이트는 노드 객체를 업데이트하는 비용보다 훨씬 적습니다. 이 메커니즘을 통해는 Kubernetes는 크게 CPU 오버 헤드 API 서버를 줄일뿐만 아니라 크게 트랜잭션 로그의 etcd 많은 수의 노드의 수천의 규모 1000에서 확장 된 크기의 성공을 감소 함수는 Kubernetes - 1.14 지역 사회에서 기본적으로 사용하도록 설정되어 있습니다.

API 서버로드 밸런싱

성능 및 가용성 고려 사항에 대한 생산 클러스터에서는 종종 여러 노드 고 가용성 클러스터는 Kubernetes를 배포합니다. 그러나 고 가용성 클러스터의 실제 작동, 부하가 여러 API 서버 사이에 발생할 수있는 것은 균형이 아니거나 클러스터 노드를 업그레이드하는 것은 실패 할 때 부분적으로, 특히에서 다시 시작합니다. 이 클러스터는 원래 직면 API 서버 배분 압력의 가용성에 의해 계획 압력, 많은에 안정을 가져왔다,하지만 극단적 인 경우에, 모든 압력은 더 이상 시스템 응답 시간의 결과로, 노드에 돌아왔다, 심지어 공격 이 차례로 노드 눈사태의 붕괴를 야기한다.

아래 그림은 모든 압력이 API 서버 중 하나에 명중하는 사례 클러스터에, 세 개의 노드의 클러스터의 API 서버 업그레이드 시뮬레이션에서 측정 된 압력이 표시, CPU 오버 헤드가 두 개의 다른 노드에 비해 훨씬 높다.

로드 밸런싱의 문제를 해결, 자연 아이디어는 부하 분산을 증가시키는 것이다. 메인로드 클러스터 하트 비트 프로세싱 노드에서, 전술 한 설명에 언급, 우리는 API 서버와 kubelet의 중간에 증가 LB, 두 개의 일반적인 아이디어가 있습니다 :

1. API 서버 측정 증가 파운드, 모든 kubelets 클라우드 공급 업체는 일반적으로는 Kubernetes 클러스터를 전달 모델이다 파운드를 연결;
2. 증가 파운드 측정 kubelet는 API 서버를 선택할 수 LB.

압력 환경 인증을 측정하여 증가 LB 것으로 위에서 언급 한 문제를 해결할 수없고, 우리는 깊이는 Kubernetes 내의 통신 메커니즘을 이해해야한다. 깊은 연구로는 Kubernetes 연결 인증 TLS 오버 헤드를 해결하기 위해,는 Kubernetes 클라이언트가 연결이 클라이언트가 대부분의 경우 같은 TLS 낮은에서 작업하는 감시자 "같은 TLS로 재 연결을 시도 할"것을 보장하기 위해 많은 노력을했다, 발견 이와 관련, 그것은 스위치 API 서버의 재 연결을 찾다을 트리거 할 수 때 유일한 예외가 발생합니다. 결과는 kubelet 후방 API 서버에 연결되어있는 경우에 우리는 기본적으로 스위칭이 발생로드되지 않습니다, 볼 것입니다. 이 문제를 해결하기 위해, 우리는 세 가지 측면을 최적화했다 :

1. API 서버 : 클라이언트가 신뢰할 수없는 가정, 요청이 패배의 오버로드로부터 자신을 보호해야합니다. 때 부하가 송신하는 임계 값을 초과 자체 409 - too many requests 알림 클라이언트 후퇴 그 자체의 부하는 클라이언트의 연결 요청이 거부되는 폐쇄함으로써, 더 높은 임계 값을 초과;
2. 클라이언트 : 시간의 기간에 빈번하게 접수 409 , 정기적으로 API 서버 완전한 개편 스위칭 다시 연결 연결 전환 API 서버를 다시 설정하려고 할 때,
3. 운영 및 유지 보수 레벨, 우리는 가지고 지터 할 수있는 업그레이드 프로세스를 피하기 위해 maxSurge = 3 가지 방법을 설정하여 API 서버를 업그레이드합니다.

도 바닥에 나타낸 모니터 채 빠르게 자동 평형 상태로 복원 할 수 재시작 두 노드 (도 지터)를 표시하면서 API 서버의 향상된 버전은 실질적으로 부하 분산을 수행 할 수있다.

목록 시계 & Cacher

목록-시계는 Kubernetes 서버가 클라이언트와 통신 핵심의 메커니즘, 정보가 업데이트 된 데이터의 모든 개체가 etcd를보고 내부 반사경에 의해 API 서버를 변경 etcd 메모리에 저장, 컨트롤러 / 또한 클라이언트를 kubelets 유사한 메커니즘에 의해 데이터 변경에 가입합니다.

어떻게 데이터를 확인하기 위해 클라이언트와 서버 사이의 통신 단절이의는 Kubernetes에 증가 글로벌 버전 번호를 채택 재 연결, 동안 손실되지 않은 경우 목록 - 시계 메커니즘을 직면 중앙 문제는, resourceVersion 달성하기 위해. 반사판 아래와 같이 이것은 반사기가 현재 서버 버전 통지 데이터의 최신 버전의 동기화되어 저장 (5) 재배 선하면 시작 위치 메모리 기록시 기록 데이터를 필요로하는 최근의 변화에 기초하여 서버 클라이언트 컴퓨팅 (7 ).

그것은 모두 매우 간단하고 신뢰성이 보이지만 ...

내부적으로 각 개체 유형은 이름에 저장되어있는 API 서버에서 storage 객체, 예를 들어있을 것입니다 :

1. 포드 저장
2. 노드 저장
3. ConfigMap 형 스토리지
4. ...

각 타입은 특정 래그 관찰자 (시나리오 등을 재시도)을 지원하는 제한된 저장 큐 가까운 변화 스토리지 오브젝트를 갖는다. 일반적으로, 모든 형태의 유형은 공간의 버전 번호를 증가 점유율 (1, 2, 3, ..., N), 즉 상술 한 바와 같이, POD 오브젝트 버전 번호가 연속을 보장하지 않는 경우에만 보장 증가된다. 위의 문제 만 kubelet 녹색 포드를 같이 단지에만 포드 관련된 노드들이 포드, 가장 일반적인 kubelet과 관심의 부분에 관심이있을 수있는 데이터를 동기화 클라이언트 목록 - 시계 메커니즘을 사용하는 경우 (2, 5).

저장 업데이트 포드 큐의 이전 변화가 큐로부터 제거 될 제한된 큐 (FIFO)이기 때문이다. 상관없이 5가 제거 된 후, 클라이언트가이 시간 API 서버 (5)와 최소 전류 큐에서 판정 될 수없는, 다시 경우 클라이언트를 업데이트 큐, 클라이언트 진행, RV = 5 인 상태로 유지 될 때의, 전술 한 바와 같이 (7 여부를 클라이언트 사이 변경에 대한 인식이 필요)가, 따라서 클라이언트가 반환하는 too old version err 모든 데이터를 클라이언트 다시 목록을 트리거합니다. 이 문제의는 Kubernetes 소개 해결하기 Watch bookmark 메커니즘 :

북마크 적시에 업데이트 반사경 필요의 내부 버전 번호를 업데이트 할 큐 클라이언트 인식 할 필요가 없었다하더라도, 핵심 아이디어는 클라이언트와 서버 사이에 "하트 비트"를 유지하는 것입니다 요약. , 최신 버전의 RV 클라이언트에 = 12 추진 버전 번호에 해당 클라이언트 서버 뒤에 있도록하는 적절한 서버에, 위와 같이. 책갈피 (성능 몇 번 개선) 재 동기화 다시 시작 API 서버 이벤트가 원래 3 %로 감소 될 수있다 필요 기능 알리 클라우드 컨테이너 플랫폼, 지역 사회는 Kubernetes - 1.15 버전으로 출시되었습니다.

Cacher 및 인덱싱

에 도시 된 바와 같이 목록 - 시계뿐만 아니라, 다른 클라이언트 액세스 모드는 직접 쿼리 API 서버입니다. 클라이언트가 여러 API 서버 노드에 걸쳐 일관성있는 데이터를 읽을 수 있도록하기 위해, API 서버 클라이언트 쿼리의 데이터 etcd을 획득 지원됩니다. 성능 관점에서 볼 때,이 몇 가지 질문을 제기 :

1. 인덱스를 지원하지 수, 클러스터 포드 쿼리 노드는 비용이 엄청나 포드 모두를 얻을 필요가;
2. 단일 쿼리 요청에 너무 많은 데이터의 요청 - 응답 모델 etcd 메모리를 많이 소모하기 때문에, API 서버 사이의 데이터 쿼리의 양을 제한하고 일반적으로 요청 etcd 및 페이징 모드를 통해 많은 양의 데이터를 완료 조회, 페이징 성능을 크게 감소 왕복 시간을 가지고;
3. 일관성을 보장하기 위해 API 서버 쿼리 etcd가 사용 Quorum read 이 쿼리의 비용이 클러스터 수준, 그것은 확장 할 수 없습니다.

이 문제를 해결하기 위해, 우리는 캐시 API 서버를 통해 일관된 데이터를 얻을 수 있습니다 클라이언트를 확인 etcd은 API 서버 및 데이터 협력 메커니즘, 아래 그림과 같이 원칙은, 전체 워크 플로우는 다음과 같다 설계 :

1. T0 고객 문의 API 서버에서;
2. API 서버 요청은 데이터 RV의 @ t0의 현재 버전을 etcd;
3. API 서버 요청은 데이터의 진행 상황을 업데이트하고 반사경 버전의 RV @ t0의 도달 대기;
4. 사용자 요청에 응답 캐시를 통해.

이러한 네임 스페이스 노드 이름 / 캐시 응답에 의해 색인 라벨에 대한 지원으로, 사용자의 요청이있을 때이 방법을 모델 클라이언트 (약 인수를 소유 할 수 있습니다 관심)의 일관성을 아프게하지 않는, 우리는 유연한 쿼리 기능을 향상시킬 수 있습니다. 이 향상된 기능은 크게 일반적으로 같은 쿼리와 같은 다른 운영의 효율성으로, 0.3S 원래 5 초에서 백만 단위 (노드 이름 인덱스를 트리거) 클러스터의 크기를 줄일 노드를 얻기 위해 한 번에 노드를 설명, 읽기 API 서버 요청 처리 능력을 향상 또한 우리는 기하 급수적으로 증가하였습니다.

컨트롤러 장애 복구

클러스터 생산에 10,000 노드는 거의 백만 객체와 컨트롤러 매장은 API 서버와 드 직렬화 오버 헤드로부터 획득 한 개체가 무시할 수없는, 그것은, 컨트롤러가 수행 한 작업을 다시 부팅하는 데 몇 분 정도 걸릴 수 있습니다 이 알리 바바 크기의 기업이 받아 들일 수있다. 아래 그림과 같이 시스템 가용성의 구성 요소 업그레이드의 영향을 줄이기 위해, 우리는 프로그램을 통해이 문제를 해결하려면 여기를 단일 시스템 중단 시간을 컨트롤러 업그레이드를 줄이기 위해 필요합니다 :

1. 데이터 컨트롤러 미리 필요한로드 대기 컨트롤러 정보원 사전 시작;
2. 메인 컨트롤러를 업그레이드 할 때 즉시 작업을 인수 할 준비를 트리거링, 리더 임대를 해제 할 수있는 이니셔티브를 취할 것입니다.

이 프로그램을 통해, 우리는 단지 지도자 임대 기다리고 준비 비정상 가동 중단 시간 (기본 15 초)을 만료 된 경우에도, 두 번째 수준 (<2 초를 업그레이드)에 데이터를 다시 동기화하는 데 몇 분 정도 걸릴 할 필요 시간 인터럽트 컨트롤러를 줄일 수 없습니다. 성능에 영향 제어기 API 서버 회복을 줄이고 이러한 개선으로 크게 제어기 MTTR을 감소시킨다. 프로그램은 또한 스케줄러에 적용됩니다.

사용자 정의 스케줄러

때문에 역사적인 이유로, 알리바바 스케줄러는 강화 된 스케줄러 섹션을 확장하지 않았기 때문에 주 사이의 관계,이 시간이 아키텍처의 자체 연구를 사용합니다. 아래 그림과 같이 여기에 단지 두 가지 기본 아이디어를 공유 :

1. 등가 클래스 : 일반 사용자 요청의 확장 기본 증설 용기 복수, 우리는 등가 클래스, 배치 공정에서 분할에 의해 큐에 대기중인 요청 술어 / 우선 순위들의 수는 현저히 감소;
2. 편안한 무작위 : 하나의 스케줄링 요청에 대해 클러스터의 후보 노드가 매우 큰 경우, 우리는 해결의 정확성을 희생 (후속 처리 일정을 입력 할 충분한 노드로 선택 후, 클러스터의 모든 노드를 평가 할 필요가 없습니다 ) 스케줄링의 성능을 향상시킬 수 있습니다.

개요

알리바바는 개선 및 최적화의 시리즈를 통해,는 Kubernetes 성공적으로 포함하여 프로덕션 환경에 적용 단일 노드 클러스터를 10000 대규모을 달성 :

1. 마지막 bbolt의 DB 스토리지 엔진 알고리즘을 기초 etcd etcd 기억 용량을 향상시키기 위해 인덱스 데이터 분리, 데이터 샤드 다른 방법을 통해 분배하고, 블록을 향상시킴으로써, 상당한 성능 개선, 장면 스토어 단일 etcd 클러스터 지원을 대량의 데이터를 etcd 크게 시스템 아키텍처의 전반적인 복잡성을 단순화, 대규모 클러스터는 Kubernetes;
2. 는 Kubernetes 가벼운 심장 박동을 방문하여, 개선 된 부하는 대부분이 방식으로 안정적인 캐쉬 대규모 클러스터 된 인덱스와리스트는 Kubernetes 성능 병목 현상을 두통 개선, ListWatch 메커니즘 북마크를 증가 HA API 서버 노드에서 여러 클러스터를 균형 완 가능한 실행 노드 클러스터;
3. 스위치 오버 중단 시간, 전체 클러스터의 가용성을 증가 할 때 뜨거운 대기로서 크게 컨트롤러 / 스케줄러 서비스를 단축;
4. 임의의 프로세스와 등가 클래스의 휴식 알고리즘 :이 개 아이디어 스케줄러 RESEARCH 가장 효과적인 성능 최적화에서 알리 바바.

개선이 시리즈를 통해 알리바바가 성공적으로 안쪽의 핵심 사업은 수천 개의 노드의는 Kubernetes 클러스터에서 실행하고, (618) 2019 살쾡이 승진 시험을 경험하고있다.

저자 소개 :

Zengfan 노래 (별칭 : 영으로), 그래서 알리 네이티브 애플리케이션 플랫폼 수석 기술 전문가.

우리는 디자인과 분산 시스템의 개발에 풍부한 경험을 보유하고 있습니다. 문의 규모의 수천의 스케줄링 시스템 관리 노드 수백에 대한 책임이 있기 때문에이 분야에서 클러스터 리소스 스케줄링에서, 클러스터 리소스 스케줄링, 자원 분리 용기, 혼합 워크로드 부서에서 실질적인 풍부한 경험이있다. 현재 가을 대규모 내부는 Kubernetes 알리 주로 담당하고, 알리는 Kubernetes 자원 이용 효율 및 응용 프로그램 게시 클러스터 안정 지원 2018 2019618 2-11 승진을 향상, 핵심 전력 사업 운영의 내부에 적용됩니다.

** "알리바바 클라우드 네이티브 마이크로 채널 대중 번호 (ID : Alicloudnative) 마이크로 서비스에 초점을, 서버를 사용하지 않는이, 컨테이너, 서비스 메쉬 및 클라우드 인기있는 기술 동향 출신, 클라우드 네이티브 대규모 상륙 연습 초점을 다른 기술 분야는 대부분의 클라우드 네이티브 개발을 이해한다 아니 공공의 기술. "**