Kubernetes용 PostgreSQL 문에 대한 간략한 개요, 우리의 선택 및 경험

고객으로부터 이러한 요청을 점점 더 많이 받고 있습니다. "우리는 Amazon RDS와 비슷하지만 더 저렴하기를 원합니다." "우리는 RDS처럼 모든 인프라에서 어디서나 이를 원합니다." Kubernetes에서 이러한 관리형 솔루션을 구현하기 위해 우리는 PostgreSQL에서 가장 인기 있는 연산자(Stolon, Crunchy Data 및 Zalando의 연산자)의 현재 상태를 살펴보고 선택했습니다.

이 기사는 이론적 관점(솔루션 검토)과 실제 관점(무엇을 선택했고 결과는 무엇인지)에서 우리가 경험한 내용입니다. 하지만 먼저 RDS를 잠재적으로 대체하기 위한 일반적인 요구 사항이 무엇인지 정의해 보겠습니다.

RDS 란 무엇입니까?

사람들이 RDS에 대해 이야기할 때 우리 경험에 따르면 이는 다음과 같은 관리형 DBMS 서비스를 의미합니다.

1. 설정이 쉽습니다.
2. 스냅샷으로 작업하고 스냅샷에서 복구할 수 있는 기능이 있습니다(바람직하게는 PITR);
3. 마스터-슬레이브 토폴로지를 생성할 수 있습니다.
4. 풍부한 확장 기능 목록이 있습니다.
5. 감사 및 사용자/액세스 관리를 제공합니다.

일반적으로 작업 구현에 대한 접근 방식은 매우 다를 수 있지만 조건부 Ansible을 사용하는 경로는 우리에게 가깝지 않습니다. (2GIS의 동료들은 다음과 같은 결과로 비슷한 결론에 도달했습니다. 그의 시도 "Postgres 기반 장애 조치 클러스터 빠른 배포 도구"를 만듭니다.)

Kubernetes 생태계에서 이러한 문제를 해결하기 위해 일반적으로 수용되는 접근 방식은 운영자입니다. Kubernetes 내부에서 실행되는 데이터베이스와 관련하여 이에 대한 자세한 내용은 Flant의 기술 이사가 이미 다음과 같이 말했습니다. 디스톨에 그의 보고서 중 하나.

NB: 간단한 연산자를 빠르게 생성하려면 오픈 소스 유틸리티에 주의하는 것이 좋습니다. 쉘 연산자. 이를 사용하면 Go에 대한 지식 없이도 Bash, Python 등 시스템 관리자에게 더 친숙한 방식으로 이 작업을 수행할 수 있습니다.

PostgreSQL에는 널리 사용되는 K8s 연산자가 몇 가지 있습니다.

• 스톨론;
• 바삭바삭한 데이터 PostgreSQL 운영자;
• Zalando Postgres 운영자.

좀 더 자세히 살펴보겠습니다.

운영자 선택

위에서 이미 언급한 중요한 기능 외에도 Kubernetes의 인프라 엔지니어로서 우리는 운영자로부터 다음을 기대했습니다.

• Git에서 배포 및 맞춤형 리소스;
• 포드 반친화성 지원;
• 노드 선호도 또는 노드 선택기 설치
• 공차 설정;
• 튜닝 기능의 가용성;
• 이해할 수 있는 기술, 심지어 명령까지.

각 요점에 대해 자세히 설명하지 않고(전체 기사를 읽은 후에도 여전히 질문이 있으면 의견에 질문하십시오) 일반적으로 클러스터 노드의 전문화에 대한보다 미묘한 설명을 위해 이러한 매개 변수가 필요하다는 점에 유의할 것입니다. 특정 용도를 위해 주문하십시오. 이를 통해 성능과 비용 간의 최적의 균형을 달성할 수 있습니다.

이제 PostgreSQL 운영자 자신에게.

1. 스톨론

스톨론 이탈리아 회사인 Sorint.lab에서 이미 언급된 보고서 DBMS 운영자들 사이에서는 일종의 표준으로 여겨졌다. 이것은 상당히 오래된 프로젝트입니다. 첫 번째 공개 릴리스는 2015년 3000월(!)에 이루어졌으며 GitHub 저장소는 거의 40명의 별과 XNUMX명 이상의 기여자를 자랑합니다.

실제로 Stolon은 사려 깊은 아키텍처의 훌륭한 예입니다.

이 운영자의 장치는 보고서 또는 프로젝트 문서. 일반적으로 장애 조치, 투명한 클라이언트 액세스를 위한 프록시, 백업 등 설명된 모든 작업을 수행할 수 있다고만 말하면 충분합니다. 또한 프록시는 아래에 설명된 다른 두 가지 솔루션과 달리 하나의 엔드포인트 서비스를 통해 액세스를 제공합니다(액세스를 위한 두 가지 서비스가 있습니다). 베이스).

그러나 스톨론은 사용자 정의 리소스 없음, 이는 Kubernetes에서 DBMS 인스턴스를 생성하기 위해 "불타오르는 케이크처럼" 쉽고 빠른 방식으로 배포할 수 없는 이유입니다. 관리는 유틸리티를 통해 수행됩니다. stolonctl, 배포 - Helm 차트를 통해, 사용자 정의 항목은 ConfigMap에 정의됩니다.

한편으로는 연산자가 실제로는 연산자가 아니라는 것이 밝혀졌습니다(CRD를 사용하지 않기 때문입니다). 하지만 한편으로는 K8s의 리소스를 원하는 방식으로 구성할 수 있는 유연한 시스템입니다.

요약하자면, 개인적으로 각 데이터베이스에 대해 별도의 차트를 시작하는 것이 가장 좋은 방법은 아닌 것 같습니다. 그래서 우리는 대안을 찾기 시작했습니다.

2. 바삭바삭한 데이터 PostgreSQL 연산자

Crunchy Data의 연산자미국의 젊은 스타트업인 는 논리적인 대안처럼 보였습니다. 공개 역사는 2017년 1300월 첫 번째 릴리스부터 시작됩니다. 이후 GitHub 저장소는 50개 미만의 별과 1.15명 이상의 기여자를 받았습니다. 1.18월의 최신 릴리스는 Kubernetes 3.11-4.4, OpenShift 1.3+ 및 XNUMX+, GKE 및 VMware Enterprise PKS XNUMX+에서 작동하도록 테스트되었습니다.

Crunchy Data PostgreSQL Operator 아키텍처는 명시된 요구 사항도 충족합니다.

관리는 유틸리티를 통해 이루어집니다. pgo그러나 Kubernetes용 사용자 지정 리소스가 생성됩니다. 따라서 운영자는 우리를 잠재적 사용자로 기쁘게 생각합니다.

• CRD를 통한 제어가 있습니다.
• 편리한 사용자 관리(CRD를 통해서도 가능)
• 다른 구성요소와의 통합 크런치 데이터 컨테이너 제품군 - PostgreSQL용 컨테이너 이미지 및 이를 사용하기 위한 유틸리티(pgBackRest, pgAudit, contrib의 확장 등 포함)의 특수 컬렉션입니다.

그러나 Crunchy Data에서 연산자를 사용하려고 시도하면 몇 가지 문제가 드러났습니다.

• 허용 가능성은 없었습니다. nodeSelector만 제공됩니다.
• 생성된 포드는 상태 저장 애플리케이션을 배포하고 있음에도 불구하고 배포의 일부였습니다. StatefulSet와 달리 배포는 디스크를 만들 수 없습니다.

마지막 결함은 재미있는 순간으로 이어집니다. 테스트 환경에서 우리는 하나의 디스크로 3개의 복제본을 실행했습니다. 로컬 저장소, 그 결과 운영자는 3개의 복제본이 작동 중이라고 보고했습니다(그러나 사실은 그렇지 않았습니다).

이 오퍼레이터의 또 다른 특징은 다양한 보조 시스템과의 사전 통합입니다. 예를 들어 pgAdmin과 pgBounce를 설치하는 것은 쉽습니다. 선적 서류 비치 사전 구성된 Grafana 및 Prometheus가 고려됩니다. 최근에는 릴리스 4.5.0-beta1 별도로 언급된 프로젝트와의 향상된 통합 pg모니터, 덕분에 운영자는 즉시 PgSQL 메트릭의 시각적 시각화를 제공합니다.

그러나 Kubernetes 생성 리소스의 이상한 선택으로 인해 우리는 다른 솔루션을 찾아야 했습니다.

3. Zalando Postgres 운영자

Zalando 제품은 오랫동안 우리에게 알려져 왔습니다. 우리는 Zalenium을 사용한 경험이 있으며 물론 다음을 시도했습니다. 패트로니 PostgreSQL용으로 널리 사용되는 HA 솔루션입니다. 회사의 창작 접근 방식에 대해 포스트그레스 연산자 작가 중 한 명인 Alexei Klyukin이 방송에서 말했습니다. 포스트그레스-화요일 #5우리는 그것을 좋아했습니다.

이는 기사에서 논의된 가장 최근의 솔루션입니다. 첫 번째 릴리스는 2018년 1300월에 이루어졌습니다. 그러나 공식 릴리스 수가 적었음에도 불구하고 이 프로젝트는 이미 GitHub에서 별 70개 이상, 최대 기여자 수(XNUMX명 이상)로 Crunchy Data 솔루션의 인기를 능가하는 등 큰 발전을 이루었습니다.

이 운영자의 "내부"에는 오랜 테스트를 거친 솔루션이 사용됩니다.

• 패트로니와 스필로 운전을 위해,
• 웨일 - 백업의 경우
• PgBouncer - 연결 풀로.

Zalando의 연산자 아키텍처가 제시되는 방법은 다음과 같습니다.

운영자는 사용자 정의 리소스를 통해 완전히 관리되고, 컨테이너에서 StatefulSet을 자동으로 생성한 다음, 포드에 다양한 사이드카를 추가하여 사용자 정의할 수 있습니다. 이 모든 것은 Crunchy Data의 연산자와 비교할 때 중요한 장점입니다.

우리는 고려된 3가지 옵션 중에서 Zalando의 솔루션을 선택했기 때문에 해당 기능에 대한 추가 설명이 적용 사례와 함께 아래에 즉시 제시됩니다.

Zalando의 Postgres 연산자 연습

Operator 배포는 매우 간단합니다. GitHub에서 현재 릴리스를 다운로드하고 디렉터리에서 YAML 파일을 적용하기만 하면 됩니다. 명단. 또는 다음을 사용할 수도 있습니다. 운영자 허브.

설치 후 설정을 잘 관리해야 합니다. 로그 및 백업용 스토리지. ConfigMap을 통해 수행됩니다. postgres-operator 연산자를 설정한 네임스페이스에 있습니다. 리포지토리가 구성되면 첫 번째 PostgreSQL 클러스터를 배포할 수 있습니다.

예를 들어 표준 배포는 다음과 같습니다.

apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
 name: staging-db
spec:
 numberOfInstances: 3
 patroni:
   synchronous_mode: true
 postgresql:
   version: "12"
 resources:
   limits:
     cpu: 100m
     memory: 1Gi
   requests:
     cpu: 100m
     memory: 1Gi
 sidecars:
 - env:
   - name: DATA_SOURCE_URI
     value: 127.0.0.1:5432
   - name: DATA_SOURCE_PASS
     valueFrom:
       secretKeyRef:
         key: password
         name: postgres.staging-db.credentials
   - name: DATA_SOURCE_USER
     value: postgres
   image: wrouesnel/postgres_exporter
   name: prometheus-exporter
   resources:
     limits:
       cpu: 500m
       memory: 100Mi
     requests:
       cpu: 100m
       memory: 100Mi
 teamId: staging
 volume:
   size: 2Gi

이 매니페스트는 다음 형식의 사이드카가 포함된 인스턴스 3개로 구성된 클러스터를 배포합니다. postgres_exporter, 이를 통해 애플리케이션 측정항목을 수집합니다. 보시다시피 모든 것이 매우 간단하며 원할 경우 문자 그대로 무제한의 클러스터를 만들 수 있습니다.

주목할 가치가 있습니다 관리용 웹 패널 - postgres-operator-ui. 운영자와 함께 제공되며 클러스터를 생성 및 삭제할 수 있을 뿐만 아니라 운영자가 만든 백업으로 작업할 수도 있습니다.

PostgreSQL 클러스터 목록

백업 관리

또 다른 흥미로운 기능은 지원입니다. 팀 API. 이 메커니즘은 자동으로 생성됩니다. PostgreSQL의 역할, 사용자 이름 결과 목록을 기반으로 합니다. 그런 다음 API를 사용하면 역할이 자동으로 생성된 사용자 목록을 반환할 수 있습니다.

문제 및 해결책

그러나 연산자를 사용하면서 곧 몇 가지 중요한 단점이 드러났습니다.

1. nodeSelector 지원 부족;
2. 백업을 비활성화할 수 없음
3. 기지 생성 기능을 사용할 때 기본 권한이 나타나지 않습니다.
4. 주기적으로 문서가 충분하지 않거나 오래되었습니다.

다행히도 그 중 많은 부분을 해결할 수 있습니다. 끝부터 시작하자 - 문제 선적 서류 비치.

아마도 백업을 등록하는 방법과 백업 버킷을 운영자 UI에 연결하는 방법이 항상 명확하지는 않다는 사실을 접하게 될 것입니다. 문서에서는 이에 대해 지나가는 말로 설명하지만 실제 설명은 PR:

1. 비밀을 만들어야 해요.
2. 매개변수로 연산자에 전달 pod_environment_secret_name 연산자 설정이 있는 CRD 또는 ConfigMap(연산자 설치 방법에 따라 다름).

그러나 결과적으로 현재로서는 이것이 불가능합니다. 그렇기 때문에 우리는 수집했습니다. 귀하의 운영자 버전 일부 추가 타사 개발이 포함되어 있습니다. 자세한 내용은 아래를 참조하세요.

백업을 위해 운영자에게 매개변수를 전달하는 경우, 즉 - wal_s3_bucket AWS S3의 액세스 키를 사용하면 모든 것을 백업할 거야: 프로덕션 기반뿐만 아니라 스테이징 기반도 있습니다. 그것은 우리에게 적합하지 않았습니다.

연산자 사용 시 PgSQL의 기본 Docker 래퍼인 Spilo에 대한 매개변수 설명에서 매개변수를 전달할 수 있다고 나와 있습니다. WAL_S3_BUCKET 비어 있으므로 백업이 비활성화됩니다. 더욱이 나는 큰 기쁨을 얻었습니다. 준비된 홍보, 우리는 즉시 포크에 받아들였습니다. 이제 추가하는 것은 충분히 쉽습니다 enableWALArchiving: false PostgreSQL 클러스터 리소스에.

예, 2명의 운영자를 실행하여 다르게 수행할 수 있었습니다. 하나는 스테이징(백업 없음)용이고 다른 하나는 프로덕션용입니다. 하지만 우리는 XNUMX개로 버틸 수 있었습니다.

좋아, 우리는 S3에 대한 액세스를 데이터베이스로 전송하는 방법을 배웠고 백업이 스토리지에 들어가기 시작했습니다. 운영자 UI에서 백업 페이지를 작동시키는 방법은 무엇입니까?

Operator UI에서는 3개의 변수를 추가해야 합니다.

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

그 후에는 백업 관리가 가능해지며, 우리의 경우 스테이징 작업이 단순화되어 추가 스크립트 없이 프로덕션에서 슬라이스를 전달할 수 있습니다.

또 다른 장점으로는 Teams API를 사용한 작업과 운영자 도구를 사용하여 데이터베이스와 역할을 생성할 수 있는 광범위한 기회가 호출되었습니다. 그러나 신흥 역할에는 기본적으로 권한이 없습니다.. 따라서 읽기 권한이 있는 사용자는 새 테이블을 읽을 수 없습니다.

왜 그런 겁니까? 코드에 있음에도 불구하고 이 필요한 GRANT항상 적용되는 것은 아닙니다. 2가지 방법이 있습니다: syncPreparedDatabases и syncDatabases. 에 syncPreparedDatabases - 섹션에 있다는 사실에도 불구하고 preparedDatabases 이 조건이 있어요 defaultRoles и defaultUsers 역할을 생성하는 데에는 기본 권한이 적용되지 않습니다. 해당 권한이 자동으로 적용되도록 패치를 준비 중입니다.

그리고 우리와 관련된 개선의 마지막 순간은 - 패치생성된 StatefulSet에 노드 선호도를 추가하는 A입니다. 우리 고객은 종종 데이터베이스 서비스를 호스팅할 가치가 없는 스팟 인스턴스를 사용하여 비용을 절감하는 것을 선호합니다. 이 문제는 관용을 통해 해결될 수 있지만 노드 선호도가 있으면 더 많은 확신을 얻을 수 있습니다.

무슨 일이야?

위의 문제를 해결한 결과, 우리는 Zalando의 Postgres Operator를 당신의 저장소매우 유용한 패치가 진행되고 있습니다. 그리고 더 큰 편의를 위해 우리는 또한 수집했습니다 도커 이미지.

포크에 허용된 PR 목록:

• 운영자를 위한 안전한 경량 Docker 이미지 구축;
• 백업 비활성화;
• k8s의 현재 버전에 대한 리소스 버전 업데이트;
• 노드 어피니티 구현.

커뮤니티가 이러한 PR을 지원하여 다음 버전의 운영자(1.6)로 업스트림할 수 있다면 좋을 것입니다.

보너스! 프로덕션 마이그레이션 성공 사례

Patroni를 사용하면 가동 중지 시간을 최소화하면서 라이브 프로덕션을 운영자에게 마이그레이션할 수 있습니다.

Spilo를 사용하면 S3 스토리지를 통해 대기 클러스터를 생성할 수 있습니다. 웨일PgSQL 바이너리 로그가 S3에 처음 저장된 후 복제본에 의해 펌핑될 때. 하지만 만약 당신이 있다면 어떨까요? 아니 오래된 인프라에서 Wal-E가 사용합니까? 이 문제에 대한 해결책은 이미 그것은 제안되었다 허브에.

PostgreSQL 논리적 복제가 구출됩니다. 그러나 우리 계획이 실패했기 때문에 발행물 및 구독을 만드는 방법에 대해 자세히 설명하지 않겠습니다.

사실 데이터베이스에는 수백만 개의 행이 포함된 여러 개의 로드된 테이블이 있었고, 게다가 지속적으로 보충되고 삭제되었습니다. 간편가입 с copy_data, 새 복제본이 마스터의 모든 콘텐츠를 복사하면 마스터를 따라잡을 수 없습니다. 콘텐츠 복사는 일주일 동안 진행되었지만 마스터를 따라잡지 못했습니다. 결국 문제 해결에 도움이 됐어요 기사 Avito의 동료: 다음을 사용하여 데이터를 전송할 수 있습니다. pg_dump. 이 알고리즘의 (약간 수정된) 버전을 설명하겠습니다.

특정 복제 슬롯에 연결된 비활성화된 구독을 만든 다음 트랜잭션 번호를 수정할 수 있다는 아이디어입니다. 생산 작업을 위한 복제본이 있었습니다. 복제본은 일관된 덤프를 생성하고 마스터로부터 변경 사항을 계속 수신하는 데 도움이 되기 때문에 이는 중요합니다.

마이그레이션 프로세스를 설명하는 후속 명령은 호스트에 대해 다음 표기법을 사용합니다.

1. 석사 — 소스 서버
2. 복제본1 - 이전 프로덕션의 스트리밍 복제본
3. 복제본2 - 새로운 논리적 복제본.

마이그레이션 계획

1. 마법사에서 스키마의 모든 테이블에 대한 구독을 생성합니다. public 기초 dbname:

psql -h master -d dbname -c "CREATE PUBLICATION dbname FOR ALL TABLES;"

2. 마스터에 복제 슬롯을 생성합니다.

psql -h master -c "select pg_create_logical_replication_slot('repl', 'pgoutput');"

3. 이전 복제본에서 복제를 중지합니다.

psql -h replica1 -c "select pg_wal_replay_pause();"

4. 마스터로부터 트랜잭션 번호를 얻습니다.

psql -h master -c "select replay_lsn from pg_stat_replication where client_addr = 'replica1';"

5. 이전 복제본에서 덤프합니다. 우리는 프로세스 속도를 높이는 데 도움이 될 여러 스레드에서 이 작업을 수행할 것입니다.

pg_dump -h replica1 --no-publications --no-subscriptions -O -C -F d -j 8 -f dump/ dbname

6. 덤프를 새 서버에 업로드합니다.

pg_restore -h replica2 -F d -j 8 -d dbname dump/

7. 덤프를 다운로드한 후 스트리밍 복제본에서 복제를 시작할 수 있습니다.

psql -h replica1 -c "select pg_wal_replay_resume();"

7. 새 논리적 복제본에 구독을 생성합니다.

psql -h replica2 -c "create subscription oldprod connection 'host=replica1 port=5432 user=postgres password=secret dbname=dbname' publication dbname with (enabled = false, create_slot = false, copy_data = false, slot_name='repl');"

8. 받기 oid 구독:

psql -h replica2 -d dbname -c "select oid, * from pg_subscription;"

9. 받았다고 하자 oid=1000. 구독에 거래 번호를 적용해 보겠습니다.

psql -h replica2 -d dbname -c "select pg_replication_origin_advance('pg_1000', 'AA/AAAAAAAA');"

10. 복제를 시작해 보겠습니다.

psql -h replica2 -d dbname -c "alter subscription oldprod enable;"

11. 구독 상태를 확인하세요. 복제가 작동해야 합니다.

psql -h replica2 -d dbname -c "select * from pg_replication_origin_status;"
psql -h master -d dbname -c "select slot_name, restart_lsn, confirmed_flush_lsn from pg_replication_slots;"

12. 복제가 시작되고 데이터베이스가 동기화된 후 전환할 수 있습니다.

13. 복제를 비활성화한 후 시퀀스를 수정해야 합니다. 잘 설명되어 있어요 wiki.postgresql.org 기사에서.

이 계획 덕분에 전환이 최소한의 지연으로 진행되었습니다.

결론

Kubernetes 연산자를 사용하면 다양한 작업을 K8s 리소스 생성으로 줄여 단순화할 수 있습니다. 그러나 그들의 도움으로 놀라운 자동화를 달성한 후에는 예상치 못한 여러 가지 미묘한 차이가 발생할 수도 있다는 점을 기억할 가치가 있으므로 운영자를 현명하게 선택하십시오.

PostgreSQL에 대해 가장 인기 있는 세 가지 Kubernetes 연산자를 검토한 후 우리는 Zalando의 프로젝트를 선택했습니다. 그리고 우리는 몇 가지 어려움을 극복해야 했지만 결과는 정말 만족스러웠습니다. 그래서 우리는 이 경험을 다른 PgSQL 설치로 확장할 계획입니다. 유사한 솔루션을 사용해 본 경험이 있다면 댓글을 통해 자세한 내용을 알려드리겠습니다!

PS

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

• «데이터베이스 및 Kubernetes(개요 및 동영상 보고서)";
• «Postgres 화요일 #5: PostgreSQL 및 Kubernetes. CI/CD. 테스트 자동화";
• «K8s의 Redis 운영자에 대한 이야기와 이 데이터베이스의 데이터를 분석하기 위한 유틸리티에 대한 간략한 검토".

출처 : habr.com