Kubernetes용 연산자: 상태 저장 애플리케이션을 실행하는 방법

Kubernetes의 상태 저장 애플리케이션 문제

상태 비저장으로 분류된 경우 애플리케이션과 서비스의 구성, 실행 및 추가 확장이 쉽습니다. 데이터를 저장하지 않고. 표준 API를 사용하여 Kubernetes에서 이러한 서비스를 실행하는 것이 편리합니다. 모든 것이 표준 구성에 따라 세부 사항이나 마법을 사용하지 않고 "즉시" 발생하기 때문입니다.

간단히 말해서, 컨테이너 클러스터에서 PHP/Ruby/Python으로 백엔드 복사본 5개를 더 시작하려면 새 서버를 XNUMX번 설정하고 소스를 복사하기만 하면 됩니다. 소스 코드와 init 스크립트가 모두 이미지에 있으므로 상태 비저장 애플리케이션의 확장은 완전히 기본이 됩니다. 컨테이너와 마이크로서비스 아키텍처 팬이라면 잘 알겠지만, 어려움은 상태 저장 앱, 즉. 데이터베이스 및 캐시(MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...)와 같은 데이터 지속성을 갖추고 있습니다. 이는 쿼럼 클러스터를 독립적으로 구현하는 소프트웨어(예: Percona XtraDB 및 Cassandra)와 별도의 관리 유틸리티가 필요한 소프트웨어(예: Redis, MySQL, PostgreSQL...) 모두에 적용됩니다.

소스 코드와 서비스 시작만으로는 더 이상 충분하지 않기 때문에 문제가 발생합니다. 몇 가지 단계를 더 수행해야 합니다. 최소한 데이터를 복사하거나 클러스터에 가입하세요. 보다 정확하게는 이러한 서비스를 사용하려면 데이터 손실이나 일시적인 사용 불가 없이 서비스를 적절하게 확장, 업데이트 및 재구성하는 방법을 이해해야 합니다. 이러한 요구 사항을 고려하는 것을 "운영 지식"이라고 합니다.

CoreOS 운영자

운영 지식을 "프로그래밍"하기 위해 작년 말 CoreOS 프로젝트 도입 된 Kubernetes 플랫폼을 위한 "새로운 종류의 소프트웨어" - Operators(영어 "운영", 즉 "운영"에서 유래).

Kubernetes의 핵심 기능을 사용하고 확장하는 운영자(포함) StatefulSet, 아래 차이점 참조) DevOps 전문가가 애플리케이션 코드에 운영 지식을 추가할 수 있습니다.

운영자의 목적 — 내부 내용(어떤 데이터와 이를 사용하여 무엇을 해야 하는지, 클러스터를 유지 관리하기 위해 어떤 명령을 실행해야 하는지)에 대해 생각하지 않고 Kubernetes 클러스터에서 여러 상태 저장 애플리케이션 엔터티를 관리할 수 있는 API를 사용자에게 제공합니다. ). 실제로 Operator는 클러스터 내 애플리케이션 작업을 최대한 단순화하여 이전에 수동으로 해결해야 했던 운영 작업의 실행을 자동화하도록 설계되었습니다.

운영자의 작동 방식

레플리카세트 Kubernetes를 사용하면 원하는 실행 Pod 수를 지정할 수 있으며 컨트롤러는 Pod 생성 및 삭제를 통해 해당 수가 유지되도록 보장합니다. Operator는 비슷한 방식으로 작동하여 필요한 수의 애플리케이션 엔터티를 지원하기 위해 추가 작업을 수행할 수 있도록 표준 Kubernetes 리소스 및 컨트롤러에 일련의 운영 지식을 추가합니다.

이것이 어떻게 다른가요? StatefulSet, 데이터 저장소나 고정 IP와 같은 상태 저장 리소스를 제공하기 위해 클러스터가 필요한 애플리케이션을 위해 설계되었습니까? 이러한 애플리케이션의 경우 운영자는 다음을 사용할 수 있습니다. StatefulSet (대신 레플리카세트)를 기본으로 제공 추가 자동화: 충돌 발생 시 필요한 조치를 수행하고, 백업을 만들고, 구성을 업데이트하는 등의 작업을 수행합니다.

따라서, 이 모든 것이 어떻게 작동합니까? 운영자는 다음을 수행하는 관리자 데몬입니다.

1. Kubernetes의 이벤트 API를 구독합니다.
2. 시스템에 대한 데이터를 수신합니다. 레플리카세트, 꼬투리, 서비스 등등.);
3. 에 대한 데이터를 받습니다 타사 리소스 (아래 예 참조)
4. 외모/변화에 반응 타사 리소스 (예를 들어 크기를 변경하려면 버전을 변경하는 등)
5. 시스템 상태의 변화에 ​​반응합니다. 레플리카세트, 꼬투리, 서비스 등등.);
6. 가장 중요 :
   1. Kubernetes API를 호출하여 필요한 모든 것을 생성합니다(다시 말하지만 자체 레플리카세트, 꼬투리, 서비스...),
   2. 몇 가지 마법을 수행합니다(간단히 말하면 Operator가 Pod 자체에 들어가서 명령을 호출한다고 생각할 수 있습니다. 예를 들어 클러스터에 가입하거나 버전을 업데이트할 때 데이터 형식을 업그레이드하는 것입니다).

실제로 그림에서 볼 수 있듯이 쿠버네티스에는 단순히 별도의 애플리케이션이 추가된다(일반 애플리케이션). 전개 с 레플리카셋)를 연산자라고 합니다. 이는 일반 꼬투리(보통 단 하나)에 거주하며 일반적으로 해당 꼬투리에만 책임이 있습니다. 네임 스페이스. 이 운영자 애플리케이션은 직접적으로는 아니지만 API를 통해 API를 구현합니다. 타사 리소스 쿠버네티스에서.

따라서 우리가 만든 후 네임 스페이스 운영자님, 추가하겠습니다 타사 리소스.

etcd의 예 (자세한 내용은 아래 참조):

apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
  name: example-etcd-cluster
spec:
  size: 3
  version: 3.1.0

Elasticsearch의 예:

apiVersion: enterprises.upmc.com/v1
kind: ElasticsearchCluster
metadata:
  name: example-es-cluster
spec:
  client-node-replicas: 3
  master-node-replicas: 2
  data-node-replicas: 3
  zones:
  - us-east-1c
  - us-east-1d
  - us-east-1e
  data-volume-size: 10Gi
  java-options: "-Xms1024m -Xmx1024m"
  snapshot:
    scheduler-enabled: true
    bucket-name: elasticsnapshots99
    cron-schedule: "@every 2m"
  storage:
    type: gp2
    storage-class-provisioner: kubernetes.io/aws-ebs

운영자 요구 사항

CoreOS는 엔지니어가 Operator 작업을 하면서 얻은 주요 패턴을 공식화했습니다. 모든 Operator가 개별적이라는 사실에도 불구하고(고유한 특성과 요구 사항이 있는 특정 애플리케이션을 위해 생성됨) 이들의 생성은 다음 요구 사항을 부과하는 일종의 프레임워크를 기반으로 해야 합니다.

1. 설치는 단일 경로를 통해 수행되어야 합니다. 전개: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - 추가 조치가 필요하지 않습니다.
2. Kubernetes에 Operator를 설치할 때 새로운 타사 유형을 생성해야 합니다. (타사 리소스). 애플리케이션 인스턴스(클러스터 인스턴스)를 시작하고 추가로 관리(버전 업데이트, 크기 조정 등)하려면 이 유형을 사용합니다.
3. 가능할 때마다 다음과 같이 Kubernetes에 내장된 기본 요소를 사용해야 합니다. 서비스 и 레플리카세트잘 테스트되고 이해하기 쉬운 코드를 사용합니다.
4. Operators의 이전 버전과의 호환성이 필요하고 사용자가 생성한 리소스의 이전 버전에 대한 지원이 필요합니다.
5. Operator가 제거되면 애플리케이션 자체는 변경 없이 계속 작동해야 합니다.
6. 사용자는 원하는 애플리케이션 버전을 정의하고 애플리케이션 버전 업데이트를 조정할 수 있어야 합니다. 소프트웨어 업데이트 부족은 운영 및 보안 문제의 일반적인 원인이므로 운영자는 이 문제에 대해 사용자를 지원해야 합니다.
7. 운영자는 Pod, 구성 및 네트워크의 잠재적인 오류를 식별하는 Chaos Monkey와 같은 도구를 사용하여 테스트해야 합니다.

etcd 연산자

연산자 구현 예 - etcd 운영자, 준비된 이번 컨셉 발표 당일. etcd 클러스터 구성은 쿼럼 유지, 클러스터 멤버십 재구성, 백업 생성 등의 필요성으로 인해 복잡할 수 있습니다. 예를 들어, etcd 클러스터를 수동으로 확장한다는 것은 새 클러스터 멤버에 대한 DNS 이름을 생성하고, 새 etcd 엔터티를 시작하고, 새 멤버에 대해 클러스터에 경고해야 함을 의미합니다(etcdctl 회원 추가). Operator의 경우 사용자는 클러스터 크기만 변경하면 됩니다. 다른 모든 작업은 자동으로 수행됩니다.

그리고 etcd도 CoreOS에서 생성되었기 때문에 해당 Operator가 먼저 나타나는 것은 매우 논리적이었습니다. 그는 어떻게 일합니까? 연산자 로직 etcd 세 가지 구성 요소에 의해 결정됩니다.

1. 관찰하다. 운영자는 Kubernetes API를 사용하여 클러스터 상태를 모니터링합니다.
2. 분석. 현재 상태와 원하는 상태(사용자 구성에 의해 정의됨) 사이의 차이점을 찾습니다.
3. 행동. etcd 및/또는 Kubernetes 서비스 API를 사용하여 감지된 차이점을 해결합니다.

이 로직을 구현하기 위해 Operator에 함수가 준비되었습니다. 생성/파괴 (etcd 클러스터 멤버 생성 및 삭제) 및 크기 조정 (클러스터 구성원 수 변경) 작동의 정확성은 Netflix의 Chaos Monkey와 유사한 유틸리티를 사용하여 확인되었습니다. etcd 포드를 무작위로 종료합니다.

etcd의 전체 작동을 위해 Operator는 다음과 같은 추가 기능을 제공합니다. 백업 (백업 복사본 생성이 자동으로 사용자에게 보이지 않음 - 구성에서는 백업 복사본 생성 빈도와 저장할 개수를 결정하고 이후에 해당 복사본에서 데이터를 복원하는 것으로 충분함) 업그레이드 (다운타임 없이 etcd 설치 업데이트)

오퍼레이터와 함께 일하는 것은 어떤 모습인가요?

$ kubectl create -f https://coreos.com/operators/etcd/latest/deployment.yaml
$ kubectl create -f https://coreos.com/operators/etcd/latest/example-etcd-cluster.yaml
$ kubectl get pods
NAME                             READY     STATUS    RESTARTS   AGE
etcd-cluster-0000                1/1       Running   0          23s
etcd-cluster-0001                1/1       Running   0          16s
etcd-cluster-0002                1/1       Running   0          8s
etcd-cluster-backup-tool-rhygq   1/1       Running   0          18s

etcd Operator의 현재 상태는 베타 버전이며 실행하려면 Kubernetes 1.5.3+ 및 etcd 3.0+가 필요합니다. 소스 코드와 문서(사용 지침 포함)는 다음에서 확인할 수 있습니다. GitHub의.

CoreOS의 또 다른 구현 예가 생성되었습니다. 프로메테우스 오퍼레이터, 그러나 아직은 알파 버전입니다(계획된 기능이 모두 구현되지는 않았습니다).

현황 및 전망

쿠버네티스 오퍼레이터 발표 이후 5개월이 지났습니다. 공식 CoreOS 저장소에는 아직 두 가지 구현만 사용할 수 있습니다(etcd 및 Prometheus용). 둘 다 아직 안정적인 버전에 도달하지 않았지만 커밋은 매일 관찰됩니다.

개발자는 "사용자가 Kubernetes 클러스터에 Postgres Operator, Cassandra Operator 또는 Redis Operator를 설치하고 오늘날 상태 비저장 웹 애플리케이션의 복제본을 배포하는 것처럼 쉽게 이러한 애플리케이션의 확장 가능한 엔터티와 작업하는 미래"를 구상합니다. 첫 번째 타사 개발자의 연산자 정말 나타나기 시작했어요:

• Elasticsearch 운영자 UPMC 기업에서;
• PostgreSQL 연산자 Crunchy Data에서(2017년 XNUMX월 말 발표);
• 루크 오퍼레이터 Ceph 기반 분산 데이터 저장 시스템 작성자(Rook은 알파 상태)
• 오픈스택 운영자 SAP CCloud에서.

2017년 XNUMX월 브뤼셀에서 열린 유럽 최대 자유 소프트웨어 컨퍼런스 FOSDEM에서 CoreOS의 Josh Wood는 Operators를 발표했습니다. 보고 (동영상은 링크에서 볼 수 있습니다!) 이는 더 넓은 오픈 소스 커뮤니티에서 이 개념의 인기를 높이는 데 기여할 것입니다.

PS 기사에 관심을 가져주셔서 감사합니다! 우리 허브를 구독하세요, DevOps 및 GNU/Linux 시스템 관리에 대한 새로운 자료와 레시피를 놓치지 않기 위해 정기적으로 게시할 예정입니다!

출처 : habr.com