🥇Pinterest에서 kubernetes 플랫폼 만들기

수년에 걸쳐 Pinterest의 300억 명의 사용자는 200억 개가 넘는 보드에 4억 개가 넘는 핀을 만들었습니다. 이러한 사용자 집단과 방대한 콘텐츠 기반에 서비스를 제공하기 위해 포털은 몇 개의 CPU로 처리할 수 있는 마이크로서비스부터 전체 가상 머신에서 실행되는 거대한 모놀리스에 이르기까지 수천 개의 서비스를 개발했습니다. 그러다 회사의 시선이 k8s에 쏠리는 순간이 왔다. Pinterest에서 "큐브"가 좋아 보이는 이유는 무엇인가요? 최근 기사 번역을 통해 이에 대해 배울 수 있습니다. 블로그 핀터레스트 엔지니어링.

따라서 수억 명의 사용자와 수억 개의 핀이 있습니다. 이러한 사용자 집단과 방대한 콘텐츠 기반에 서비스를 제공하기 위해 우리는 몇 개의 CPU로 처리할 수 있는 마이크로서비스부터 전체 가상 머신에서 실행되는 거대한 모놀리스에 이르기까지 수천 개의 서비스를 개발했습니다. 또한 CPU, 메모리 또는 I/O 액세스가 필요할 수 있는 다양한 프레임워크가 있습니다.

이러한 도구 모음을 유지 관리하는 과정에서 개발 팀은 다음과 같은 여러 가지 과제에 직면합니다.

엔지니어가 프로덕션 환경을 실행하는 데 통일된 방법은 없습니다. 상태 비저장 서비스, 상태 저장 서비스 및 활발하게 개발 중인 프로젝트는 완전히 다른 기술 스택을 기반으로 합니다. 이로 인해 엔지니어를 위한 전체 교육 과정이 만들어졌고 인프라 팀의 작업도 심각하게 복잡해졌습니다.
자체 가상 머신을 보유한 개발자는 내부 관리자에게 엄청난 부담을 안겨줍니다. 결과적으로 OS나 AMI 업데이트와 같은 간단한 작업에는 몇 주, 몇 달이 걸립니다. 이로 인해 겉으로는 절대적으로 일상적인 상황에서 작업량이 증가합니다.
기존 솔루션 위에 글로벌 인프라 관리 도구를 만드는 데 어려움이 있습니다. 가상 머신의 소유자를 찾는 것이 쉽지 않기 때문에 상황은 더욱 복잡해집니다. 즉, 이 용량을 인프라의 다른 부분에서 작동하기 위해 안전하게 추출할 수 있는지 알 수 없습니다.

컨테이너 오케스트레이션 시스템은 워크로드 관리를 통합하는 방법입니다. 프로젝트에 관련된 모든 리소스가 하나의 중앙 집중식 시스템에서 관리되므로 개발 속도가 향상되고 인프라 관리가 단순화됩니다.

그림 1: 인프라 우선순위(신뢰성, 개발자 생산성 및 효율성)

Pinterest의 클라우드 관리 플랫폼 팀은 8년에 K2017을 발견했습니다. 2017년 상반기까지 우리는 API와 모든 웹 서버를 포함한 대부분의 생산 기능을 문서화했습니다. 이후 컨테이너 솔루션 조정, 클러스터 구축 및 작업을 위한 다양한 시스템에 대한 철저한 평가를 수행했습니다. 2017년 말에 우리는 Kubernetes를 사용하기로 결정했습니다. 개발자 커뮤니티에서 매우 유연하고 널리 지원되었습니다.

지금까지 우리는 Kops를 기반으로 자체 클러스터 부팅 도구를 구축하고 네트워킹, 보안, 메트릭, 로깅, ID 관리 및 트래픽과 같은 기존 인프라 구성 요소를 Kubernetes로 마이그레이션했습니다. 또한 리소스에 대한 워크로드 모델링 시스템을 구현했는데, 그 복잡성은 개발자에게 숨겨져 있습니다. 이제 우리는 클러스터의 안정성을 보장하고 확장하며 새로운 클라이언트를 연결하는 데 중점을 두고 있습니다.

Kubernetes: Pinterest 방식

우리 엔지니어들이 좋아할 플랫폼인 Pinterest 규모의 Kubernetes를 시작하려면 많은 어려움이 따릅니다.

대기업으로서 우리는 인프라 도구에 막대한 투자를 해왔습니다. 예를 들어 인증서 처리 및 키 배포를 처리하는 보안 도구, 트래픽 제어 구성 요소, 서비스 검색 시스템, 가시성 구성 요소, 로그 및 메트릭 디스패치 구성 요소가 있습니다. 이 모든 것이 수집된 이유는 다음과 같습니다. 우리는 시행착오의 일반적인 경로를 거쳤기 때문에 새 플랫폼에서 기존 휠을 다시 만드는 대신 이 모든 장비를 Kubernetes의 새 인프라에 통합하고 싶었습니다. 이 접근 방식은 모든 애플리케이션 지원이 이미 존재하고 처음부터 새로 만들 필요가 없기 때문에 마이그레이션을 전반적으로 단순화했습니다.

반면에 Kubernetes 자체의 부하 예측 모델(예: 배포, 작업 및 데몬 세트)은 우리 프로젝트에 충분하지 않습니다. 이러한 유용성 문제는 Kubernetes로 전환하는 데 큰 장애물입니다. 예를 들어, 서비스 개발자들이 로그인 설정이 누락되거나 올바르지 않다고 불평하는 것을 들었습니다. 또한 동일한 사양과 작업으로 수백 개의 복사본이 생성될 때 템플릿 엔진의 잘못된 사용이 발생하여 악몽 같은 디버깅 문제가 발생했습니다.

동일한 클러스터에서 서로 다른 버전을 유지하는 것도 매우 어려웠습니다. 모든 문제, 버그 및 업데이트와 함께 동일한 런타임 환경의 여러 버전에서 동시에 작업해야 하는 경우 고객 지원의 복잡성을 상상해 보십시오.

Pinterest 사용자 속성 및 컨트롤러

엔지니어가 Kubernetes를 더 쉽게 구현하고 인프라를 단순화하고 속도를 높이기 위해 자체 사용자 정의 리소스 정의(CRD)를 개발했습니다.

CRD는 다음 기능을 제공합니다.

다양한 기본 Kubernetes 리소스를 결합하여 단일 워크로드로 작동합니다. 예를 들어 PinterestService 리소스에는 배포, 로그인 서비스 및 구성 맵이 포함됩니다. 이를 통해 개발자는 DNS 설정에 대해 걱정할 필요가 없습니다.
필요한 애플리케이션 지원을 구현합니다. 사용자는 비즈니스 로직에 따라 컨테이너 사양에만 집중하면 되며, CRD 컨트롤러는 필요한 모든 초기화 컨테이너, 환경 변수 및 포드 사양을 구현합니다. 이는 개발자에게 근본적으로 다른 수준의 편안함을 제공합니다.
CRD 컨트롤러는 또한 기본 리소스의 수명 주기를 관리하고 디버그 가용성을 향상시킵니다. 여기에는 원하는 사양과 실제 사양의 조정, CRD 상태 업데이트, 이벤트 로그 유지 관리 등이 포함됩니다. CRD가 없으면 개발자는 여러 리소스를 관리해야 하므로 오류 가능성이 높아질 뿐입니다.

다음은 컨트롤러가 관리하는 PinterestService 및 내부 리소스의 예입니다.

위에서 볼 수 있듯이 사용자 정의 컨테이너를 지원하려면 init 컨테이너와 여러 추가 기능을 통합하여 보안, 가시성 및 네트워크 트래픽을 제공해야 합니다. 또한 구성 맵 템플릿을 생성하고 배치 작업을 위한 PVC 템플릿 지원을 구현했으며 여러 환경 변수를 추적하여 ID, 리소스 소비 및 가비지 수집을 추적했습니다.

개발자가 구성을 추가로 유지 관리하고 디버깅하는 것은 고사하고 CRD 지원 없이 이러한 구성 파일을 직접 작성하기를 원한다는 것은 상상하기 어렵습니다.

애플리케이션 배포 워크플로

위 이미지는 Pinterest 사용자 정의 리소스를 Kubernetes 클러스터에 배포하는 방법을 보여줍니다.

개발자는 CLI 및 사용자 인터페이스를 통해 Kubernetes 클러스터와 상호 작용합니다.
CLI/UI 도구는 Artifactory에서 워크플로 구성 YAML 파일 및 기타 빌드 속성(동일한 버전 ID)을 검색한 다음 이를 Job Submission Service에 제출합니다. 이 단계를 수행하면 프로덕션 버전만 클러스터에 전달됩니다.
JSS는 Kubernetes를 포함한 다양한 플랫폼을 위한 게이트웨이입니다. 여기에서 사용자가 인증되고 할당량이 발행되며 CRD 구성이 부분적으로 확인됩니다.
JSS 측에서 CRD를 확인한 후 해당 정보를 k8s 플랫폼 API로 전송합니다.
CRD 컨트롤러는 모든 사용자 리소스의 이벤트를 모니터링합니다. CR을 기본 k8s 리소스로 변환하고, 필요한 모듈을 추가하고, 적절한 환경 변수를 설정하고, 컨테이너화된 사용자 애플리케이션이 충분한 인프라 지원을 받을 수 있도록 기타 지원 작업을 수행합니다.
그런 다음 CRD 컨트롤러는 수신된 데이터를 Kubernetes API에 전달하여 스케줄러에서 처리하고 프로덕션에 투입할 수 있도록 합니다.

주의: 이 배포의 사전 출시 작업 흐름은 새로운 k8s 플랫폼의 첫 번째 사용자를 위해 만들어졌습니다. 우리는 현재 새로운 CI/CD와 완전히 통합하기 위해 이 프로세스를 개선하는 과정에 있습니다. 즉, Kubernetes와 관련된 모든 것을 알려드릴 수는 없습니다. 다음 블로그 게시물인 "Pinterest용 CI/CD 플랫폼 구축"에서 이 방향에 대한 우리의 경험과 팀의 진행 상황을 공유할 수 있기를 기대합니다.

특수자원의 종류

Pinterest의 특정 요구 사항을 기반으로 다양한 워크플로에 맞게 다음 CRD를 개발했습니다.

PinterestService는 오랫동안 실행되어 온 상태 비저장 서비스입니다. 당사의 핵심 시스템 중 다수는 이러한 서비스 세트를 기반으로 합니다.
PinterestJobSet은 전체 주기 배치 작업을 모델링합니다. Pinterest의 일반적인 시나리오는 여러 작업이 다른 유사한 프로세스에 관계없이 동일한 컨테이너를 병렬로 실행한다는 것입니다.
PinterestCronJob은 작은 주기적인 로드와 함께 널리 사용됩니다. 이는 보안, 트래픽, 로그 및 지표를 담당하는 Pinterest 지원 메커니즘을 사용한 기본 cron 작업을 위한 래퍼입니다.
PinterestDaemon에는 인프라 데몬이 포함되어 있습니다. 이 제품군은 클러스터에 더 많은 지원을 추가함에 따라 계속해서 성장하고 있습니다.
PinterestTrainingJob은 Tensorflow 및 Pytorch 프로세스로 확장되어 다른 모든 CRD와 동일한 수준의 런타임 지원을 제공합니다. Pinterest는 Tensorflow 및 기타 기계 학습 시스템을 적극적으로 사용하기 때문에 이를 중심으로 별도의 CRD를 구축해야 할 이유가 있었습니다.

우리는 또한 데이터 웨어하우스 및 기타 상태 저장 시스템에 곧 적용될 PinterestStatefulSet에 대한 작업도 진행 중입니다.

런타임 지원

애플리케이션 포드가 Kubernetes에서 실행되면 자동으로 인증서를 받아 자신을 식별합니다. 이 인증서는 비밀 저장소에 액세스하거나 mTLS를 통해 다른 서비스와 통신하는 데 사용됩니다. 한편, Container Init Configurator와 Daemon은 컨테이너화된 애플리케이션을 실행하기 전에 필요한 모든 종속성을 다운로드합니다. 모든 것이 준비되면 트래픽 사이드카와 데몬은 클라이언트가 이를 발견할 수 있도록 Zookeeper에 모듈의 IP 주소를 등록합니다. 애플리케이션이 시작되기 전에 네트워크 모듈이 구성되었기 때문에 이 모든 것이 작동합니다.

위는 워크로드에 대한 런타임 지원의 일반적인 예입니다. 다른 유형의 워크로드에는 약간 다른 지원이 필요할 수 있지만 모두 포드 수준 사이드카, 노드 수준 또는 가상 머신 수준 데몬의 형태로 제공됩니다. 우리는 이 모든 것이 관리 인프라 내에 배포되고 애플리케이션 전체에서 일관성을 갖도록 보장하여 궁극적으로 기술 작업 및 고객 지원 측면에서 부담을 크게 줄입니다.

테스트 및 QA

우리는 기존 Kubernetes 테스트 인프라 위에 엔드투엔드 테스트 파이프라인을 구축했습니다. 이 테스트는 모든 클러스터에 적용됩니다. 우리의 파이프라인은 제품 클러스터의 일부가 되기 전에 많은 수정을 거쳤습니다.

테스트 시스템 외에도 시스템 구성 요소의 상태, 리소스 소비 및 기타 중요한 지표를 지속적으로 모니터링하여 사람의 개입이 필요할 때만 알려주는 모니터링 및 경고 시스템이 있습니다.

대안

우리는 돌연변이 액세스 컨트롤러 및 템플릿 시스템과 같은 맞춤형 리소스에 대한 몇 가지 대안을 살펴보았습니다. 그러나 모두 상당한 운영상의 어려움이 있으므로 우리는 CRD 경로를 선택했습니다.

사이드카, 환경 변수 및 기타 런타임 지원을 도입하기 위해 변이 승인 컨트롤러가 사용되었습니다. 그러나 CRD에서는 이러한 문제가 발생하지 않으면 리소스 바인딩, 수명주기 관리 등 다양한 문제에 직면하게 됩니다.

참고 : Helm 차트와 같은 템플릿 시스템도 유사한 구성으로 애플리케이션을 실행하는 데 널리 사용됩니다. 하지만 우리의 업무 애플리케이션은 템플릿을 사용하여 관리하기에는 너무 다양합니다. 또한 지속적인 배포 중에 템플릿을 사용할 때 오류가 너무 많이 발생합니다.

다가오는 작업

현재 우리는 모든 클러스터에서 혼합 로드를 처리하고 있습니다. 다양한 유형과 규모의 프로세스를 지원하기 위해 우리는 다음 영역에서 작업합니다.

클러스터 모음은 확장성과 안정성을 위해 여러 클러스터에 대규모 애플리케이션을 배포합니다.
애플리케이션 연결 및 SLA를 생성하기 위한 클러스터 안정성, 확장성 및 가시성을 보장합니다.
애플리케이션이 서로 충돌하지 않도록 리소스 및 할당량을 관리하고 클러스터 규모를 당사에서 제어합니다.
Kubernetes에서 애플리케이션을 지원하고 배포하기 위한 새로운 CI/CD 플랫폼입니다.

출처 : habr.com

Pinterest에서 kubernetes 플랫폼 만들기