이 튜토리얼 집합에서는 주요 Google Kubernetes Engine(GKE) 기능 및 서비스를 학습하는 데 집중할 수 있도록 일부 계획 고려사항이 간소화되었습니다. 이 튜토리얼 집합에 설명된 것과 비슷한 고유한 Google Kubernetes Engine 환경을 만들기 전에 몇 가지 추가적인 계획을 고려해야 합니다. 이러한 고려사항에는 클러스터 관리 수준, 네트워킹, 가용성 유형이 포함되어 있습니다.
네트워킹
GKE 클러스터에는 신중한 IP 주소 계획이 필요합니다. 선택한 네트워킹 옵션은 GKE 클러스터의 아키텍처에 영향을 미칩니다. 이러한 옵션 중 일부는 구성 후 변경할 수 없으며, 변경하려면 클러스터를 다시 만들어야 합니다.
이 튜토리얼 집합에서는 항상 VPC 네이티브 모드 네트워킹을 사용하는 Autopilot 모드 클러스터를 사용합니다. VPC 네이티브 클러스터는 GKE 노드에서 별칭 IP 주소 범위를 사용하며 공유 VPC에서 클러스터를 만드는 데 필요합니다. VPC 기반 클러스터는Google Cloud 경로를 사용하지 않고도 경로 기반 클러스터보다 더 쉽게 확장되므로 라우팅 제한을 초과할 가능성이 적습니다.
이 튜토리얼 집합에서는 Autopilot 모드를 사용하는 리전별 GKE 클러스터를 만듭니다. Autopilot 클러스터는 프로덕션 워크로드에 사용할 수 있는 최적화된 클러스터 구성으로 사전 구성됩니다.
또는 기본 인프라에서 더 많은 고급 구성 유연성을 얻기 위해 표준 모드 클러스터를 사용할 수 있습니다.
네임스페이스를 사용하면 애플리케이션을 구성하고 구성요소를 서로 격리할 수 있습니다. 각 네임스페이스에는 포드, 서비스, 배포와 같은 자체 리소스 집합이 있습니다. 예를 들어 모든 프런트엔드 서비스의 네임스페이스와 백엔드 서비스의 네임스페이스를 만들 수 있습니다. 이 그룹화를 사용하면 서비스를 쉽게 관리하고 액세스를 제어할 수 있습니다.
이 튜토리얼 집합에서는 Cymbal Bank 샘플 애플리케이션의 포드 및 서비스를 단일 네임스페이스에 배포합니다. 이 접근 방법은 배포 복잡성을 줄여주지만 프로덕션 환경에서와 같이 네임스페이스를 사용하여 서로 다른 팀 및 사용자에게 리소스를 할당할 수 없습니다. 여러 네임스페이스를 사용하는 프로덕션에 즉시 사용 가능한 보다 안전한 Cymbal Bank 샘플 애플리케이션 예시를 위해서는 Cymbal Bank 애플리케이션 아키텍처를 참조하세요.
포드 중단 예산
포드 중단 예산(PDB) 정책은 시스템을 변경할 때 포드가 동시에 작동 중지되는 것을 방지하여 앱 성능을 보장하고 복제된 애플리케이션에서 동시에 사용 불가능한 포드 수를 제한하는 데 도움이 됩니다.
이 튜토리얼 집합에서는 PDB를 구성하고 사용하지 않습니다. 장애를 시뮬레이션하는 튜토리얼을 완료하면 서비스 및 노드가 모두 예상한 대로 응답합니다. 자체 워크로드를 배포하면 노드의 PDB가 노드 드레이닝을 차단할 수 있습니다.
PDB를 사용하는 경우 노드 차단 및 드레이닝을 시도하기 전에 구성을 검토하세요. 노드가 성공적으로 드레이닝되지 않으면 예약된 유지보수 이벤트에 문제가 있을 수 있습니다.
[[["이해하기 쉬움","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,["# Learning Path: Scale applications - Production considerations\n\n[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview)\n\n*** ** * ** ***\n\nIn this set of tutorials, some of the planning considerations are simplified\nso that you can focus on learning key Google Kubernetes Engine (GKE) features and\nservices. Before you start to create your own Google Kubernetes Engine environment similar\nto the one described in this set of tutorials, there are some additional\nplanning considerations to keep in mind. These considerations include the\ncluster management level, networking, and availability types.\n\nNetworking\n----------\n\nGKE clusters require careful IP address planning. The networking\noptions that you choose impact the architecture of your GKE\nclusters. Some of these options can't be changed after they're configured\nwithout recreating the cluster.\n\nIn this set of tutorials, you use Autopilot mode clusters that always\nuse VPC-native mode networking. VPC-native\nclusters use alias IP address ranges on GKE nodes, and are\nrequired for creating clusters on Shared VPCs. VPC-native\nclusters scale more easily than routes-based clusters without consuming\nGoogle Cloud routes and so are less susceptible to hitting routing\nlimits.\n\nBefore you create your own GKE environment and deploy workloads,\nreview the following networking guidance:\n\n- [GKE network overview](/kubernetes-engine/docs/concepts/network-overview)\n- [Best practices for GKE networking](/kubernetes-engine/docs/best-practices/networking)\n- [Plan IP addresses for GKE](/kubernetes-engine/docs/concepts/gke-ip-address-mgmt-strategies)\n\nCluster modes\n-------------\n\nIn this set of tutorials you create a regional GKE cluster that\nuses Autopilot mode. Autopilot clusters are pre-configured\nwith an optimized cluster configuration that is ready for production workloads.\nYou can alternatively use Standard mode clusters for more advanced\nconfiguration flexibility over the underlying infrastructure.\n\nFor a more comprehensive overview, review the planning documents that start with\nthe\n[cluster configuration choices](/kubernetes-engine/docs/concepts/types-of-clusters).\n\nNamespaces\n----------\n\nNamespaces let you organize your applications and isolate components from each\nother. Each namespace has its own set of resources, such as Pods, Services, and\nDeployments. For example, you can create a namespace for all your frontend\nservices and a namespace for your backend services. This grouping makes it\neasier to manage your services and to control access to them.\n\nIn this set of tutorials, you deploy the Pods and Services for the Cymbal Bank\nsample application into a single namespace. This approach reduces deployment\ncomplexity, but doesn't let you use namespaces to assign resources to different\nteams and users, as you might do in a production environment. For a more secure\nand production-ready example of the Cymbal Bank sample application that uses\nmultiple namespaces, see\n[Cymbal Bank application architecture](/architecture/enterprise-application-blueprint/cymbal-bank).\n\nPod disruption budgets\n----------------------\n\nPod Disruption Budget (PDB) policies help ensure app performance by preventing\nPods going down at the same time when you make a change to the system and limit\nthe number of simultaneously unavailable Pods in a replicated application.\n\nIn this set of tutorials, you don't configure and use PDBs. When you complete\nthe tutorial to simulate failure, your Services and nodes should all respond as\nexpected. When you deploy your own workloads, PDBs on nodes might block node\ndraining.\n\nIf you use PDBs, review your configuration before you try to cordon and drain\nnodes. If the nodes can't successfully drain, you might have problems with\nscheduled maintenance events.\n\nWhat's next\n-----------\n\nGet started by completing the\n[first tutorial to a deploy a single GKE cluster](/kubernetes-engine/docs/learn/scalable-apps-basic-deployment)\nthat runs a microservices-based application."]]
