K8S 멀티클러스터 여정

헤이 하브르!

우리는 Exness 플랫폼 팀을 대표합니다. 이전에 우리 동료들은 이미 다음과 같은 기사를 썼습니다. k8s용 프로덕션 준비 이미지. 오늘은 서비스를 Kubernetes로 마이그레이션한 경험을 공유하고 싶습니다.

우선, 논의할 내용을 더 잘 이해할 수 있도록 몇 가지 숫자를 제공합니다.

• 우리 개발 부서는 자급자족하는 QA, DevOps 및 Scrum 프로세스를 갖춘 100개 이상의 팀을 포함하여 10명 이상의 인력으로 구성되어 있습니다. 개발 스택 - Python, PHP, C++, Java 및 Golang. 
• 테스트 및 프로덕션 환경의 규모는 각각 컨테이너 약 2000개입니다. 그들은 자체 가상화 및 VMware에서 Rancher v1.6을 실행하고 있습니다. 

자극

그들이 말했듯이, 영원히 지속되는 것은 없으며 Rancher는 꽤 오래 전에 버전 1.6에 대한 지원 종료를 발표했습니다. 그렇습니다. 1.6년이 넘는 시간 동안 우리는 이를 준비하는 방법과 발생하는 문제를 해결하는 방법을 배웠습니다. 그러나 결코 해결되지 않는 문제에 직면하는 경우가 점점 더 많아지고 있습니다. Rancher XNUMX에는 또한 권리 발행을 위한 골화된 시스템이 있어 거의 모든 것을 할 수도 있고 아무것도 할 수도 없습니다.

독점 가상화를 통해 데이터 스토리지와 보안에 대한 통제력이 향상되었지만 회사의 지속적인 성장, 프로젝트 수 및 요구 사항을 고려하면 감당하기 어려운 운영 비용이 발생했습니다.

우리는 IaC 표준을 따르고, 필요한 경우 지리적 위치에 상관없이 공급업체에 제한 없이 신속하게 용량을 확보하고 신속하게 폐기할 수 있기를 원했습니다.

첫 번째 단계

우선, 우리는 팀이 개발 주기를 더 빠르게 하고 성능을 제공하는 플랫폼과 상호 작용하는 데 드는 운영 비용을 최소화할 수 있는 최신 기술과 솔루션에 의존하고 싶었습니다. 
 
물론 우리 마음에 가장 먼저 떠오른 것은 쿠버네티스였지만, 우리는 흥분하지 않고 그것이 올바른 선택인지 알아보기 위해 약간의 조사를 했습니다. 오픈소스 솔루션만 평가했는데, 불공정한 싸움에서 쿠버네티스가 무조건 승리했습니다.  

다음은 클러스터 생성을 위한 도구를 선택하는 문제였습니다. 우리는 가장 인기 있는 솔루션인 kops, kubespray, kubeadm을 비교했습니다.

우선, kubeadm은 일종의 "자전거" 발명가처럼 우리에게 너무 복잡한 경로로 보였고 kops에는 충분한 유연성이 없었습니다.

우승자는 다음과 같습니다.

우리는 모두가 동일한 "클러스터"를 공유하는 이전 리소스 관리 패턴과 대략 유사한 것을 다시 만들기 위해 자체 가상화와 AWS를 실험하기 시작했습니다. 이제 10개의 소형 가상 머신으로 구성된 첫 번째 클러스터가 생겼으며 그 중 두 개는 AWS에 있습니다. 우리는 그곳으로 팀을 이주시키려고 노력하기 시작했고 모든 것이 "좋은" 것처럼 보였고 이야기는 끝날 수도 있었지만...

첫 번째 문제

Ansible은 kubespray의 기반이며 IaC를 따를 수 있는 도구가 아닙니다. 노드를 커미셔닝/해제할 때 무언가 지속적으로 잘못되어 일종의 개입이 필요했으며, 다른 OS를 사용할 때 플레이북이 다르게 동작했습니다. . 클러스터의 팀과 노드 수가 늘어남에 따라 플레이북을 완료하는 데 점점 더 오랜 시간이 걸리고 있다는 것을 알게 되었고, 그 결과 우리의 기록은 3,5시간이 되었습니다. 여러분의 기록은 어떻습니까? 🙂

그리고 kubespray는 단지 Ansible인 것처럼 보이며 언뜻 보면 모든 것이 명확하지만 다음과 같습니다.

여정이 시작될 때 작업은 AWS와 가상화에서만 용량을 시작하는 것이었지만 자주 발생하듯이 요구 사항이 변경되었습니다.
 


이를 고려하여 리소스를 하나의 오케스트레이션 시스템으로 결합하는 기존 패턴이 적합하지 않다는 것이 분명해졌습니다. 클러스터가 매우 멀리 떨어져 있고 다른 공급자에 의해 관리되는 경우입니다. 

뿐만 아니라. 모든 팀이 동일한 클러스터 내에서 작업할 때 잘못 설치된 NodeSelector가 있는 다양한 서비스가 다른 팀의 "외부" 호스트로 이동하여 그곳의 리소스를 활용할 수 있으며, 오염이 설정된 경우 하나 또는 다른 서비스가 작동하지 않는다는 지속적인 요청이 있었습니다. 인적 요인으로 인해 올바르게 배포되지 않았습니다. 또 다른 문제는 비용을 계산하는 것이었습니다. 특히 노드 전체에 서비스를 분산시키는 문제를 고려했습니다.

별도의 이야기는 직원에게 권리를 부여하는 것이었습니다. 각 팀은 클러스터의 "수장"이 되어 클러스터를 완전히 관리하기를 원했는데, 이는 팀이 기본적으로 서로 독립적이기 때문에 완전한 붕괴를 초래할 수 있습니다.

무엇을해야 하는가?

위 사항과 보다 독립적이기를 바라는 팀의 바람을 고려하여 우리는 하나의 팀 - 하나의 클러스터라는 간단한 결론을 내렸습니다. 

그래서 우리는 두 번째 것을 얻었습니다.

그리고 세 번째 클러스터는 다음과 같습니다. 

그런 다음 우리는 생각하기 시작했습니다. XNUMX년 안에 우리 팀이 두 개 이상의 클러스터를 갖게 된다고 가정해 보겠습니다. 예를 들어, 다른 지리적 영역에 있습니까, 아니면 다른 공급자의 통제를 받고 있습니까? 그리고 그들 중 일부는 일부 테스트를 위해 임시 클러스터를 신속하게 배포할 수 있기를 원할 것입니다. 

완전한 Kubernetes가 올 것입니다! 이것은 일종의 MultiKubernetes인 것으로 밝혀졌습니다. 

동시에 우리 모두는 이러한 모든 클러스터를 어떻게든 유지 관리하고, 클러스터에 대한 액세스를 쉽게 관리할 수 있을 뿐만 아니라 수동 개입 없이 새 클러스터를 생성하고 기존 클러스터를 폐기할 수 있어야 합니다.

Kubernetes 세계에서의 여정이 시작된 지 어느 정도 시간이 지났고 우리는 사용 가능한 솔루션을 재검토하기로 결정했습니다. 이미 시장에 존재하는 것으로 밝혀졌습니다 - Rancher 2.2.

연구의 첫 번째 단계에서 Rancher Labs는 이미 버전 2의 첫 번째 릴리스를 만들었지만 몇 가지 매개 변수를 사용하여 외부 종속성 없이 컨테이너를 시작하거나 공식 HELM 차트를 사용하여 매우 빠르게 올릴 수 있었지만 조잡해 보였습니다. 우리는 이것이 개발될지 아니면 빨리 폐기될지 이 결정에 의존할 수 있는지 알 수 없었습니다. UI 자체의 클러스터 = 클릭 패러다임도 우리에게 적합하지 않았고 RKE는 다소 좁은 범위에 초점을 맞춘 도구이기 때문에 RKE에 얽매이고 싶지 않았습니다. 

버전 Rancher 2.2는 이미 더 실행 가능한 모양을 갖고 있으며 이전 버전과 함께 많은 외부 공급자와의 통합, 권한 및 kubeconfig 파일의 단일 배포 지점, kubectl 시작과 같은 즉시 사용할 수 있는 흥미로운 기능을 많이 갖추고 있습니다. UI에서 귀하의 권리가 있는 이미지, 중첩된 네임스페이스(일명 프로젝트). 

Rancher 2를 중심으로 이미 커뮤니티가 형성되어 있었고 이를 관리하기 위해 HashiCorp Terraform이라는 공급자가 만들어졌는데, 이는 우리가 모든 것을 하나로 모으는 데 도움이 되었습니다.

어떻게 된 거예요

결과적으로 우리는 다른 모든 클러스터뿐만 아니라 이에 연결된 많은 클러스터에 액세스할 수 있는 Rancher를 실행하는 하나의 작은 클러스터를 갖게 되었습니다. 이들 클러스터에 대한 액세스는 관계없이 ldap 디렉터리에 사용자를 추가하는 것만큼 간단하게 부여될 수 있습니다. 위치 및 사용하는 공급자의 리소스.

gitlab-ci 및 Terraform을 사용하여 클라우드 공급자 또는 자체 인프라에서 모든 구성의 클러스터를 생성하고 이를 Rancher에 연결할 수 있는 시스템이 생성되었습니다. 이 모든 작업은 IaC 스타일로 수행됩니다. 여기서 각 클러스터는 저장소에 의해 설명되고 상태는 버전화됩니다. 동시에 대부분의 모듈은 외부 저장소에서 연결되므로 남은 것은 변수를 전달하거나 인스턴스에 대한 사용자 정의 구성을 설명하는 것뿐입니다. 이는 코드 반복 비율을 줄이는 데 도움이 됩니다.

물론, 우리의 여정은 아직 끝나지 않았으며 모든 클러스터의 로그 및 메트릭을 사용하는 단일 작업 지점, 서비스 메시, 멀티 클러스터에서 로드를 관리하기 위한 gitops 등과 같은 흥미로운 작업이 여전히 많이 남아 있습니다. 우리의 경험이 흥미로웠기를 바랍니다! 

이 기사는 플랫폼 엔지니어 A. Antipov, A. Ganush가 작성했습니다. 

출처 : habr.com