Vero를 사용하여 Kubernetes 클러스터의 이야기 이동
10719 단어 KubernetesEKSvelerotech
배경.
약 반년 전 제가 속한 기업들은 EC2 실례에 kops를 사용해 만든 Kubbernetes 클러스터를 이용했습니다.그러나 EKS 등 임원인 Kubbernetes 클러스터에 비해 클러스터 관리와 버전 업그레이드가 쉽지 않고, 클러스터 자체도 2년 이상 지속해서 운영되고 있어 EKS로 이전할 계획이다.나는 이 방면의 말이 매우 흔하다고 생각한다.
다행히도 Kubbernetes 클러스터를 새로 구축하는 것 자체는 그리 어렵지 않지만, 클러스터에 있는 앱 등을 기존 클러스터에서 새 클러스터로 옮기는 작업에는 상당한 시간이 걸린다.
yaml이 선언적으로 썼기 때문에 헬름이나 쿠스토미즈처럼 빠르게 옮길 수 있을 것 같지만, 새로운 Operator를 넣은 것과 달리 몇 년간 활용된 앱이 작동하는 상태였다.Kubbernetes 클러스터 자체가 상태와 동일한 상태이기 때문에 Helm 등 install에도 어떤 의존 관계 때문에 Pod가 작동하지 않습니다.
Dev의 집단은 Helm으로 이동하려고 시도했지만 상술한 문제도 상당히 번거롭다. Dev 환경이 정상적으로 작동하지 못하는 시간이 발생하고 있다.심야에 Prod의 클러스터 이동이 이뤄졌지만, 장시간 클러스터가 움직일 수 없는 상태는 피해야 하기 때문에 클러스터의 자원을 이동하기 위해 버로(Verero)라는 도구를 사용했다.
What`s Velero
Velero는 VMware에서 OSS로 공개된 Kubernetes 클러스터의 백업, 재부팅, 마이그레이션 등을 위한 도구다.여기에서 가져온 백업에는 Deployment와ConfigMap 등 자원이 포함되어 있으며 kube-api-server를 시작하는 데 사용되는 매개 변수 등은 포함되지 않습니다.자원의 상태를 완전하게 보존하면 이해하기 쉬울 것이다.
Verero 를 선택한 이유
Verero를 선택한 주요 이유는 다음과 같습니다.
옛 클러스터의 Deployment는 대부분
extensions/v1beta1을 사용했지만, 새 클러스터는 에이피버젼을 사용할 수 없기 때문에 헬름 등 애플을 사용하면 오류가 발생할 수 있다.Velero는 각 버전의 차이를 회복하는 단계에서 적당한 ApiVersion(Deployment
apps/v1을 흡수했다.Verero의 주요 사용 방법
다음은 Vererero의 사용 방법에 대한 간략한 설명입니다.
CLI 설치
$ brew install velero
release page
$ tar -xvf <RELEASE-TARBALL-NAME>.tar.gz
$ velero version
Verero에 설치된 클러스터
벨로로에는 pluggin의 기관이 있어 EKS와 GKE 등 임원인 Kubbernetes에 대해 S3 등의 백업을 간단하게 설정할 수 있다.
여기 물통 이름이랑 구역이 있어요.
$ CLUSTER_NAME=sample-cluster
$ VELERO_BUCKET=eks-stdm-dev
$ AWS_REGION=ap-northeast-1
$ kubectl config use-context sample-cluster
$ velero install \
--provider aws \
--plugins velero/velero-plugin-for-aws:v1.0.1 \
--bucket $VELERO_BUCKET \
--backup-location-config region=$AWS_REGION \
--snapshot-location-config region=$AWS_REGION \
--secret-file ~/.aws/credentials
---------------------------------
$ kubectl get all -n velero
NAME READY STATUS RESTARTS AGE
pod/velero-649db948f4-qcj5q 0/1 PodInitializing 0 12s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/velero 0/1 1 0 13s
NAME DESIRED CURRENT READY AGE
replicaset.apps/velero-649db948f4 1 1 0 13s
백업 시도 & 목록
실제 백업을 한 후에 다시 자원 복원 여부를 확인합니다.
차리다
테스트 응용 프로그램과 type LB를 만듭니다.helm로nginx를 설치해 보도록 하겠습니다.
$ helm repo add nginx-stable https://helm.nginx.com/stable
$ helm repo add nginx-stable https://helm.nginx.com/stable
$ helm repo update
$ helm install -n staging my-release nginx-stable/nginx-ingress
$ helm list -n staging
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
my-release staging 1 2020-09-29 19:00:15.409846 +0900 JST deployed nginx-ingress-0.6.1 1.8.1
$ > kubectl get all -n staging
NAME READY STATUS RESTARTS AGE
pod/my-release-nginx-ingress-54fc64c4c5-zctr8 1/1 Running 0 51s
pod/wordpress-578744754c-kzlv5 1/1 Running 0 79m
pod/wordpress-mysql-5b697dbbfc-9chw6 1/1 Running 0 79m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/my-release-nginx-ingress LoadBalancer 10.100.191.241 a9a607b886c61463c9ab34a2b1cf294f-1084391947.ap-northeast-1.elb.amazonaws.com 80:32222/TCP,443:30894/TCP 51s
service/wordpress LoadBalancer 10.100.163.187 ae3784ca27723485c83b86836f87090e-809501219.ap-northeast-1.elb.amazonaws.com 80:32688/TCP 79m
service/wordpress-mysql ClusterIP None <none> 3306/TCP 79m
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/my-release-nginx-ingress 1/1 1 1 51s
deployment.apps/wordpress 1/1 1 1 79m
deployment.apps/wordpress-mysql 1/1 1 1 79m
NAME DESIRED CURRENT READY AGE
replicaset.apps/my-release-nginx-ingress-54fc64c4c5 1 1 1 51s
replicaset.apps/wordpress-578744754c 1 1 1 79m
replicaset.apps/wordpress-mysql-5b697dbbfc 1 1 1 79m
백업 생성
Verero 백업은 CLI 에서 수행합니다.필요에 따라 원하는 시간에 백업하는 방법과 지정된 시간에 정기적으로 백업하는 방법이 있다.이번에는 단발 백업입니다.
$ velero backup create staging-backup --include-namespaces staging
$ velero backup get
staging-backup Completed 0 0 2020-xx-xx 19:02:00 +0900 JST 29d default <none>
자원 삭제
이전에 Deploy의 각 namespace 에셋을 삭제합니다.
$ kubectl delete namespace staging
$ kubectl get all -n staging
No resources found in staging namespace.
원상회복
백업과 마찬가지로 재시작도 CLI에서 시작됩니다.
--from-backup 옵션에서 복구할 백업 지정$ velero restore create --from-backup staging-backup
$ kubectl get all -n staging
NAME READY STATUS RESTARTS AGE
pod/my-release-nginx-ingress-54fc64c4c5-zctr8 1/1 Running 0 8s
...
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/my-release-nginx-ingress LoadBalancer 10.100.245.48 ae075cd90574b4c0f90fc8811b49956c-957111671.ap-northeast-1.elb.amazonaws.com 80:30882/TCP,443:30129/TCP 8s
...
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/my-release-nginx-ingress 1/1 1 1 8s
...
NAME DESIRED CURRENT READY AGE
replicaset.apps/my-release-nginx-ingress-54fc64c4c5 1 1 1 8s
...
$ helm3 list -n staging
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
my-release staging 1 2020-09-29 19:00:15.409846 +0900 JST deployed nginx-ingress-0.6.1 1.8.1
여기에는 Deployment의 복구 백업, 자원 이름 필터 등 기능만 소개합니다.자세한 내용은 문서를 참조하십시오.
방금 많이 썼지만plugen 형식으로 백업 주소와 백업, 복구 시 행동을 확장할 수 있습니다
클러스터 간 마이그레이션
집단 간의 백업과 복구 기본 절차도 마찬가지다.
이전 단계에 따라 백업이 수행된 이전 클러스터에 Vero를 설치합니다.
클러스터 간 복구 인증은 시크릿 값 공유를 통해 인증됩니다.
Secret은 이전 그룹 측면의velero namespace의 Secret 값
cloud-credentials을 사용하기 때문에 파일에 저장됩니다.$ kubectl get secrets/cloud-credentials -n velero --template={{.data.cloud}} | base64 -D >> secret.txt
$ velero install \
--secret-file=secret.txt \
--provider aws \
--backup-location-config region=AWS_REGION \
--snapshot-location-config region=AWS_REGION \
--plugins=velero/velero-plugin-for-aws:v1.0.1 \
--bucket VELERO_BUCKET
stagingnamespace 백업만 만들었어요.$ velero backup create cluster-migration-staging --include-namespaces staging
$ velero restore create --from-backup cluster-migration-staging
$ kubectl get all -n staging
NAME READY STATUS RESTARTS AGE
pod/wordpress-578744754c-gj7h5 0/1 ContainerCreating 0 31s
...
Velero의 이동을 사용하는데 어려운 점이 있어요.
마지막으로 Verero를 사용하여 마이그레이션하는 데 어려움을 겪는 몇 가지 사항을 살펴보겠습니다.
Job 처리
내가 사용한 버로(v1.5.1)에서 Job이 Job을 다시 시작할 때 Compolete라면 Job 자원 자체는 존재하지 않지만 Pod가 Complete가 아니라면 Job가 만든 Pod도 Pod 자원으로 복원된다.
이 상태에서 Pod 리소스와 Job 리소스를 복원할 때 대상 클러스터 중 Job과 연관된 두 개의 Pod(옛 클러스터의 Job에서 만든 Pod+새 클러스터의 Job에서 만든 Pod)를 재부팅하면 만들어진다.
질문
이 그룹이 이동할 때 Helm2 시스템에서 Helm3 시스템을 업데이트합니다.Helm2시스템과 Helm3시스템이 Helm이 관리하는 자원에 대한 조작이 다르기 때문에 Helm에서 자원을 정확하게 식별할 수 없는 문제가 발생했다.
헬름이 인식할 수 있도록 헬름이 제대로 인식할 수 있도록 스크립트를 준비했다.
시크릿 정보 처리
일반적으로 클러스터 백업을 수행할 때 시크릿의 내용이 표시되므로 주의해야 합니다.
대상 S3과 같은 ACL을 백업하여 권한을 제한하거나 복구 객체에서 시크릿을 제거해야 합니다.
최후
상당히 추천하다
Reference
이 문제에 관하여(Vero를 사용하여 Kubernetes 클러스터의 이야기 이동), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://zenn.dev/tommy/articles/98cfca27e2ccb1텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
좋은 웹페이지 즐겨찾기
