모든 GitOps 설정은 동일한 순간을 맞이합니다. 무언가 잘못되었을 때, 누군가 프로덕션 환경에서 kubectl scale을 실행하고, 그 수정이 작동합니다. 그 후 일어나는 일은 사고 전에 거의 확인되지 않는 두 가지 설정에 달려 있습니다. 바로 GitRepo의 자체 복구 기능과 클러스터의 일시 중지 기능입니다.저는 Rancher 2.15.1과 Fleet(저는 SUSE에서 근무하므로 편향될 수 있습니다)를 사용하여 실험실에서 세 가지 조합을 모두 실행했습니다. 세 개의 EKS 클러스터: Kubernetes 1.36의 dev 및 staging, 1.35의 prod. 사례 1과 2는 공개 rancher/fleet-examples 리포지토리의 guestbook 앱을 사용했으며, 프론트엔드 Deployment는 3개의 복제본으로 설정되었습니다. 사례 3은 제 자체 리포지토리의 podinfo Helm 차트를 사용했습니다. 모든 수동 변경은 Rancher UI의 scale 버튼을 통해 이루어졌으며, 이는 Deployment의 scale 하위 리소스에 PATCH 요청을 보내는데, 이는 kubectl scale이 만드는 요청과 동일합니다.
kubectl scale을 실행하고, 그 수정이 작동합니다. 그 후 일어나는 일은 사고 전에 거의 확인되지 않는 두 가지 설정에 달려 있습니다. 바로 GitRepo의 자체 복구 기능과 클러스터의 일시 중지 기능입니다.저는 Rancher 2.15.1과 Fleet(저는 SUSE에서 근무하므로 편향될 수 있습니다)를 사용하여 실험실에서 세 가지 조합을 모두 실행했습니다. 세 개의 EKS 클러스터: Kubernetes 1.36의 dev 및 staging, 1.35의 prod. 사례 1과 2는 공개 rancher/fleet-examples 리포지토리의 guestbook 앱을 사용했으며, 프론트엔드 Deployment는 3개의 복제본으로 설정되었습니다. 사례 3은 제 자체 리포지토리의 podinfo Helm 차트를 사용했습니다. 모든 수동 변경은 Rancher UI의 scale 버튼을 통해 이루어졌으며, 이는 Deployment의 scale 하위 리소스에 PATCH 요청을 보내는데, 이는kubectl scale이 만드는 요청과 동일합니다.