본고에서 우리는 Aerospike’s Kubernetes operator의 기초 지식과 우리가 직면한 몇 가지 공사 도전에 어떻게 대응해야 하는지를 소개할 것이다.우리는 항공사가 직면한 기술적 도전에 대해 토론할 것이다.

Kubernetes 계산은 무엇입니까?

Kubernetes는 클러스터에서 컨테이너화된 어플리케이션의 배포 자동화 및 일상적인 관리를 지원하도록 설계되었습니다.다음은 Aerospike DB 운영자의 세부 사항을 깊이 있게 이해하기 전에 이러한 개념과 용어를 이해해야 하는 관건적인 개념과 용어들입니다.
리소스는 특정 유형의 API 객체 컬렉션을 저장하는 Kubernetes API 중 하나입니다.
자원의 몇 가지 예는 내장된 POD, 그들의 배치나 상태 집합 만들기, POD에서 실행되는 응용 프로그램을 공개하는 서비스, 기밀이 아닌 데이터를 키 값으로 저장하는 ConfigMap을 포함한다.
컨트롤러는 집단 상태의 제어 순환을 감시하고 필요할 때 변경하거나 변경을 요청합니다.
사용자 지정 리소스는 API를 클러스터로 가져옵니다.이것은 기본 Kubernetes 설치에서는 사용할 수 없는 Kubernetes API 확장자입니다.이것은 특정 Kubernetes 설치에 대한 맞춤형 설정을 대표하며, 상당히 흔하다.
사용자 정의 리소스 정의(CRD) 파일은 사용자 고유의 객체 유형을 정의하고 API 서버가 전체 라이프 사이클을 처리하도록 합니다.
운영자는 k8s API의 클라이언트이며 사용자 정의 리소스의 컨트롤러 역할을 합니다.
요약: 리소스와 사용자 정의 리소스는 특정 응용 프로그램(이 경우 Aerospike 데이터베이스)과 관련된 세부 사항을 정의합니다.컨트롤러와 조작원은 각각 자원과 사용자 정의 자원을 제어하여 복잡한 분포식 응용 프로그램의 배치와 관리에 구조를 제공한다.
인터넷 규모의 수요를 만족시키기 위해 사람들은 새로운 복잡한 분포식 체계 구조를 개발하였다.또한 끊임없이 발전하는 응용 프로그램의 경쟁 수요를 만족시키기 위해 더욱 유연한 개발 모델을 채택했다.자동화를 위한 기초를 제공함으로써 조작원은 인원 원가를 최소화하고 더욱 중요한 것은 중복적인 임무를 하는 사람의 실적의 가변성을 등식에서 제거하는 것이다.
시각적 해석.녹색: 쿠베르네트스 자원;노란색: 사용자 정의 자원.크레디트: 나탈리 피스토노비치.

Aerospike의 특징

Aerospike는 실시간 데이터 플랫폼으로 수십억 개의 사무를 운영하고 서버의 점유 공간을 줄일 수 있다.it의 성격과 고객의 요구가 그것을 위해 무엇을 할 수 있는지, 어떻게 할 수 있는지에 대해 특수한 고려 요소를 도입했다.
Aerospike Kubernetes 운영자는 데이터베이스 클러스터를 배포하고 주기 관리와 관련된 모든 사항을 처리합니다.예를 들면 다음과 같습니다.

클러스터 위아래 확장(클러스터당 노드 수 및 노드당 리소스 할당)

서버 버전 업그레이드 및 다운그레이드

YAML 기반 구성을 Aerospike 구성으로 변환

랙 감지 관리

클러스터 액세스 제어 관리

다중 클러스터 XDR 설정

보안: TLS, 사용자 관리 등

상기 모든 프로젝트의 모니터링

많은 활동 부품이 있는데, 우리가 자동화 정도가 높을수록, 인위적인 오류의 공간은 작아진다.

3 공정 과제

Aerospike 데이터베이스의 특수성과 사용 방식 때문에 우리는 여러 가지 재미있는 공사 도전에 부딪혔다.여기 세 개 있어요.

1. 영구 데이터

모든 크레인에는 전용 저장 공간이 있다.이런 저장은pod가 다시 시작되더라도 데이터가 변하지 않기를 원하기 때문에 지속적이어야 한다.
따라서 비헤이비어 논리는 다음과 같습니다.
볼륨을 처음 할당하는 경우에는 해당 볼륨을 지웁니다.
컴퓨터 메모리처럼 저장 공간이 비어 있다고 가정할 수는 없다.
크레인을 다시 시작하는 볼륨이라면 데이터를 보존하십시오.
pod는 설정을 변경할 때 다시 시작할 수도 있고 하드웨어 고장일 수도 있습니다.이번에는 유효한 저장 값이기 때문에 볼륨에 존재하는 데이터가 필요합니다.
문제는 크레인이 새 것인지 재가동된 것인지를 판단할'쿠베르니테스 방법'이 없다는 점이다.pod가 설정 변경으로 다시 시작된 장면에서 이미지도 변경되었을 가능성이 높고 모든 지표가 0으로 초기화되었습니다.
우리가 제시한 해결 방안은 init 용기에서 리셋 로고를 사용하는 것입니다.이것들은 용기가 운행되기 전에 운행하는 용기들이다.init 용기에서 데이터를 지우고 설정에 로고를 추가합니다.
이렇게 하면pod가 다시 시작될 때 로고가 거기에 있습니다. 데이터를 지워서는 안 된다는 뜻입니다.

2. 스크롤 업데이트 중단

스크롤 업데이트가 있고 10개의 노드에서 서버 버전을 업데이트하고 있다고 가정하십시오.
중간에, 너는 네가 중단하고 굴러야 한다는 것을 깨달았다.무슨 일이 일어날까요?
화면 표시

Node 1…...Updated with v5.6
Node 2…...Updated with v5.6
Node 3…...Updated with v5.6

이것이 바로 네가 클릭해서 중지하는 곳이다.
네가 다음에 보고 싶은 건.

Node 1…...Updated with v5.5
Node 2…...Updated with v5.5
Node 3…...Updated with v5.5

... 이 아니라

Node 4…...Updated with v5.6
Node 5…...Updated with v5.6
…
Node 10.....Updated with v5.6
Node 1…...Updated with v5.5
Node 2…...Updated with v5.5
Node 3…...Updated with v5.5

이것은 명령을 실행하는 과정에서 명령을 중단해야 한다는 것을 의미합니다.
따라서 우리는 매번 조작한 후에 대장 요청을 다시 조회하는 방식으로 설정을 실현했다.기본적으로 운영자는 API에 "이제 어떻게 하나요?"
이렇게 노드 번호 3을 새 버전으로 업데이트한 후 다음 단계는 "지금 무엇을 해야 합니까?"라고 묻는 것입니다.3개의 노드는 이전 API가 이 점에 적용되었음을 나타냅니다!
효율을 높이기 위해 조작원은 응답 지연을 요구한다.예를 들어 노드가 이전 과정에 있다고 가정하면 2초가 걸린다.이 경우 운영자는 API에 "이제 어떻게 하지? 2초 안에 답장해 달라"고 묻는다.
API는 2초 동안 많은 일이 발생할 수 있기 때문에 조작자가 최신 명령을 받을 수 있도록 응답을 유지할 것이다.
단도직입적이고 뻔한 일로 들리나요?물론 모든 운영자가 이렇게 실현하는 것은 아니다.

3. 초규모 구현

클라우드는 신속한 가동과 유지보수에 매우 적합하다. 사실상 현재 많은 회사들이 그 서비스를 클라우드로 이전하고 있다.
당신의 고객 규모가 매우 클 때 무슨 일이 일어날까요?
우리의 많은 고객들은 이미 PB 분야(즉 당구, 수십억 이후의 한 분야)에 있고 일부 고객들은 EB 분야(수조 억원)에 진출하고 있다.물론 이들은 모두 밀리초의 동일한 SLA를 유지하기를 원한다.
우리는 모두 구름이 고르지 않다는 것을 안다.당신이 얻은 하드웨어는 최소한의 CPU를 약속하지만, 이것은 모든 CPU가 똑같은 속성을 가지고 있다는 것을 의미하지는 않는다.
아주 큰 범위 내에서 이런 미세한 차이들이 나타나기 시작했다.
Aerospike의 구조는 디스크가 무겁다.자원을 공유하는 것은 분명히 한 덩어리로 나눌 수 있지만 크기를 조절하기는 어렵다는 것을 의미한다.이것은 기계 한 대가 소식에 대한 반응이 느릴 수도 있다는 것을 의미할 수 있다.분포식 데이터베이스에서 데이터를 불러오는 원 메시지를 제외하고 원 메시지도 사방으로 이동한다. 예를 들어 동기화에 사용되는 원 메시지이다.성능 사양에 따라 지연이 발생하여 업그레이드에 문제가 발생할 수 있습니다.
또 다른 잠재적인 문제는 인터넷이다. 인터넷이 개인이 아닐 때 일부분을 얻을 수 있지만 공유해야 한다.만약 당신이 시끄러운 이웃이 있다면, 그들은 당신의 행동을 떨어뜨리고, 이것은 등급 연결 효과를 일으킬 것이다.
이들 중단 중 어느 것도 예측하기 어려워 조작원만으로는 해결할 수 없다.
이처럼 규모가 큰 일부 고객들이 하고 있는 해결 방안은 프라이빗 클라우드다.이러한 설정에서 전체 호스트를 소유하고 내부에서 자원을 분할합니다.이러한 설정에서 일부 좋은 실천은 일부 초용량 문제에 대한 예산을 제정하고 현지와 최대한 통신하여 지연의 영향을 최대한 줄이는 것을 포함한다.
이 설정에서 Kubernetes 조작부호도 훌륭합니다.쿠버네트스는 구글의 개인 클라우드에서 시작했기 때문이다.

한번 되돌아보도록 하겠습니다.

우리는 자원과 자원 통제에 관한 쿠버넷의 기본 용어를 소개했다.
그리고 우리는 자신의 운영자를 구축할 때 고속으로 대규모로 운행하는 분포식 데이터베이스로서 우리의 고려 사항을 토론했다.마지막으로, 우리는 우리가 직면한 세 가지 공사 도전과 그것을 어떻게 해결하는지 토론했다.
조작원 코드는 GitHub에서 시작되었습니다. 읽기, 학습, 공헌을 환영합니다!