GKE는 조직 내에서 백업으로 보호되지 않는 클러스터를 식별하는 인사이트를 생성합니다. 이러한 인사이트를 가져오려면 Google Cloud 콘솔, Google Cloud CLI, CLUSTER_BACKUP_PLAN_NOT_CREATED 하위유형이 포함된 Recommender API를 사용하여 인사이트 및 추천 보기 지침을 따릅니다.
GKE에서 백업 계획이 없는 클러스터를 식별하는 방법
GKE는 다음 기준에 따라 클러스터를 보호하기 위한 백업 계획을 만들어야 하는지 결정합니다.
클러스터가 임시 클러스터가 아닙니다. 즉, GKE 클러스터가 다음 기준을 모두 충족합니다.
클러스터가 7일 이상 존재했습니다.
클러스터가 다음 영역 또는 리전 중 하나에 있습니다.
영역: us-central1-a, us-central1-b, us-central1-c, us-central1-f,
us-east1-b, us-east1-c 또는 us-east1-d
Backup for GKE로 클러스터를 백업해야 하는지 평가하려면 다음 기준을 고려하세요.
스테이트풀(Stateful) 애플리케이션 실행: 스테이트풀(Stateful) 애플리케이션은 손실 및 손상에 취약한 상태를 유지합니다. 백업은 영역, 리전, 워크로드, 사용자 과실로 인한 중단에 대한 최상의 방어를 제공합니다.
빠른 애플리케이션 롤백이 중요: 결함, 업그레이드 실패 또는 손상이 발생할 경우 스테이트풀(Stateful) 및 스테이트리스(Stateless) 애플리케이션을 모두 알려진 정상 상태로 복구합니다. 백업에서 복구하면 애플리케이션을 재배포하는 것보다 복구 시간이 단축되는 경우가 많습니다.
백업을 사용하면 여러 시점을 저장하여 유연성을 높일 수 있습니다.
사이버 공격으로부터 보호 필요: 변경 불가능한 암호화된 백업을 만들고 이러한 백업을 최소한의 기간 동안 삭제되지 않도록 잠그는 방식으로 사이버 공격 위협의 영향을 대비하세요.
스테이트풀(Stateful) 워크로드와 스테이트리스(Stateless) 워크로드 모두 백업으로 이점을 얻을 수 있습니다. 이 기준 중 하나 이상이 클러스터에 적용되는 경우 백업을 구성하는 것이 좋습니다.
추천에 따른 조치
Backup for GKE를 사용 설정하고 클러스터의 백업 계획을 만들어야 한다고 판단되면 다음 안내를 따르세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["# Protect clusters with Backup for GKE\n\nAutopilot Standard\n\n*** ** * ** ***\n\nYou can use Google Kubernetes Engine (GKE) clusters to run mission-critical\nworkloads, which must be resilient to many types of disruptions, including\ninfrastructure failures, user errors, and cyber attacks.\n\nWith [Backup for GKE](/kubernetes-engine/docs/add-on/backup-for-gke/concepts/backup-for-gke), you can:\n\n- Back up configurations and persistent volume data to make workloads resilient to disruption.\n- Restore workloads from backups if disruptions occur.\n- Achieve business-critical Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO).\n- Streamline day-to-day operations by cloning production configuration and data for use cases such as sandbox testing, and the creation of test and development environments.\n\nGKE monitors your clusters and uses the [Recommender service](/recommender/docs/overview)\nto provide guidance for how you can optimize your usage of the platform.\nGKE detects opportunities to make workloads more resilient to disruptions by\nenabling Backup for GKE.\n\nTo learn more about how to manage insights and recommendations from Recommender,\nsee [Optimize your usage of GKE with insights and recommendations](/kubernetes-engine/docs/how-to/optimize-with-recommenders).\n\nIdentify clusters unprotected by Backup for GKE\n-----------------------------------------------\n\nGKE generates insights that identify clusters within your organization that\naren't protected by backups. To get these insights, follow the instructions to\n[view insights and recommendations](/kubernetes-engine/docs/how-to/optimize-with-recommenders#view-insights-recs)\nusing the Google Cloud console, the Google Cloud CLI, or the Recommender API with\nthe `CLUSTER_BACKUP_PLAN_NOT_CREATED` subtype.\n\nHow GKE identifies clusters without a backup plan\n-------------------------------------------------\n\nGKE uses the following criteria to determine that you should create a backup\nplan to protect your cluster:\n\n- The cluster is not ephemeral, meaning that the GKE cluster meets all of the following criteria:\n\n - The cluster has existed for at least seven days.\n - The cluster is in one of the following zones or regions:\n\n - **Zone** : `us-central1-a`, `us-central1-b`, `us-central1-c`, `us-central1-f`, `us-east1-b`, `us-east1-c`, or `us-east1-d`\n - **Region** : `us-east1`\n - The cluster is running.\n\n - The cluster is not an [alpha cluster](/kubernetes-engine/docs/concepts/alpha-clusters).\n\n- The cluster has no associated Backup for GKE backup plan.\n\nAssess if your cluster needs data protection with Backup for GKE\n----------------------------------------------------------------\n\nConsider the following criteria to assess whether you should back up your\ncluster with Backup for GKE:\n\n- **Running stateful applications**: Stateful applications retain state, which is vulnerable to loss and corruption. Backups provide the best defense against disruptions due to zonal, regional, workload, or user-induced failures.\n- **Quick application rollback is important**: Recover both stateful and stateless applications to a known healthy state in the event of faults, failed upgrades, or corruption. A recovery from backups can often lead to quicker recovery times compared to redeploying your application. With backups, you can store multiple points in time for greater flexibility.\n- **Need protection from cyber attack**: Prepare for the impact of cyber attack threats by creating immutable and encrypted backups, and locking those backups against deletion for a minimum amount of time.\n\nBoth stateful and stateless workloads can benefit from backups. Consider\nconfiguring backups if one or more of this criteria applies to your cluster.\n\nAct on the recommendation\n-------------------------\n\nIf you've determined that you should enable Backup for GKE and create a\nbackup plan for your cluster, follow these instructions:\n\n1. [Enable Backup for GKE API](/kubernetes-engine/docs/add-on/backup-for-gke/how-to/install).\n2. [Enable Backup for GKE for a cluster](/kubernetes-engine/docs/add-on/backup-for-gke/how-to/enable-gke-cluster).\n3. [Create a backup plan](/kubernetes-engine/docs/add-on/backup-for-gke/how-to/backup-plan#console).\n\nWhat's next\n-----------\n\n- [Optimize your usage of GKE with insights and recommendations](/kubernetes-engine/docs/how-to/optimize-with-recommenders)\n- [Restore a backup](/kubernetes-engine/docs/add-on/backup-for-gke/how-to/restore)"]]
