이 가이드에서는 구성 동기화에서 종속 항목이 작동하는 방법과 자체 종속 항목을 지정하는 방법을 설명합니다.
구성 동기화에서는 특정 객체를 클러스터에 동기화할 때 해당 객체 간의 암시적 종속 항목을 자동으로 감지합니다.
예를 들어 네임스페이스 객체는 항상 해당 네임스페이스의 객체보다 먼저 적용되고 CustomResourceDefinition(CRD) 객체는 항상 이 유형의 커스텀 리소스가 적용되기 전에 적용됩니다. 암시적 종속 항목의 삭제 순서는 반대로 적용됩니다. 네임스페이스가 해당 네임스페이스의 객체 다음에 삭제되고 CRD는 해당 유형의 커스텀 리소스 다음에 삭제됩니다.
또한 depends-on 주석을 사용하여 명시적 종속 항목을 설정할 수 있습니다.
예를 들어 Wordpress 배포 전에 MySQL StatefulSet가 시작되게 하여 Wordpress가 시작되기 전에 데이터베이스를 적용 및 준비할 수 있습니다.
요구사항
RootSync 및 RepoSync API를 사용 설정해야 합니다.
kubectl을 사용하여 구성 동기화를 수동으로 설치했고 RootSync 및 RepoSync API가 사용 설정되지 않았으면 ConfigManagement 객체를 마이그레이션해야 합니다.
제한사항: 종속 항목은 해당하는 종속 항목과 동일한 정보 소스에 있어야 합니다. 종속 항목은 해당 종속 항목과 동일한 RootSync 또는 RepoSync 객체에서 관리해야 하므로 모든 리소스가 동일한 ResourceGroup에 있어야 합니다.
그룹 적용
클러스터에 리소스를 동기화하면 구성 동기화가 직접 또는 간접 종속 항목을 포함하는 리소스를 여러 적용 그룹으로 분할합니다. 하나의 적용 그룹은 서로에 대해 직접 또는 간접 종속 항목이 없는 리소스만으로 구성됩니다. 종속 항목이 없는 적용 그룹이 먼저 적용됩니다.
활성화 및 조정
객체를 활성화(적용 또는 프루닝)하면 컨트롤러에 따라 객체가 조정되는 데 시간이 걸릴 수 있습니다. 예를 들어 배포가 적용될 때 기본 포드가 즉시 준비되지 않을 수 있습니다. 기본 포드가 준비되면 배포가 조정됩니다. 이러한 유형의 객체에 대해 구성 동기화는 여러 조건 유형을 검사하여 객체가 조정되었는지 확인합니다. 자세한 내용은 sigs.k8s.io/cli-utils에서 확인할 수 있습니다.
depends-on 주석을 사용하면 구성 동기화에서 원하는 순서로 객체를 적용할 뿐만 아니라 종속 객체를 적용하기 전에 종속 항목 객체가 조정되었는지 확인합니다.
종속 항목 객체가 기본 조종 제한 시간인 5분 이내에 조정되지 않을 경우 구성 동기화는 다음 동기화 기간이 될 때까지 종속 객체를 적용하지 않습니다. spec.override.reconcileTimeout을 설정하여 기본 조정 제한 시간을 재정의할 수 있습니다.
객체에 depends-on 주석 추가
종속 항목을 지정하려면 config.kubernetes.io/depends-on 주석을 종속 항목 객체를 참조하는 값과 함께 종속 객체에 추가합니다.
[[["이해하기 쉬움","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,["# Declare dependencies between resource objects\n\nThis guide teaches you how dependencies work in Config Sync\nand how to specify your own dependencies.\n\nConfig Sync automatically detects implicit dependencies\nbetween specific objects when syncing them to the cluster.\nFor example, the Namespace objects are always applied before any\nobjects in those Namespaces, and a CustomResourceDefinition (CRD) object is always applied before\nany custom resource of this type is applied. Likewise, deletion ordering is\nreverse for these implicit dependencies: Namespaces are deleted after objects\nin that namespace, and CRDs are deleted after Custom Resources of that type.\n\nYou can also set explicit dependencies by using the `depends-on` annotation.\nFor example, you might want your MySQL StatefulSet to start up before your\nWordpress Deployment, so that your database is applied and ready before\nWordpress starts.\n\nRequirements\n------------\n\n- RootSync and RepoSync APIs need to be enabled.\n If you installed Config Sync manually using kubectl, and don't have\n RootSync and RepoSync APIs enabled, you need to\n [migrate your ConfigManagement object](/kubernetes-engine/enterprise/config-sync/docs/how-to/migrate-multi-repo).\n\n- **Limitation:** Dependencies must be in the same as\n their dependent. Dependencies must be managed by the same RootSync or RepoSync\n object as their dependents, which ensures all resources are in the same\n ResourceGroup.\n\nApply group\n-----------\n\nWhen syncing resources to the cluster, Config Sync divides resources that have direct or indirect dependencies into different apply groups. One apply group only consists of resources without direct or indirect dependencies on each others. The apply group in which resources do not have any dependencies will be applied first.\n\nActuation and reconciliation\n----------------------------\n\nWhen an object is actuated (either applied or pruned), it\ncan take a while for the object\nto be reconciled by its controller. For example, when a Deployment is applied,\nthe underlying Pods might not be ready immediately. After the underlying Pods\nare ready, the Deployment is reconciled. For different types of objects,\nConfig Sync checks different types of conditions to verify\nif an object is reconciled. More details can be found in\n[sigs.k8s.io/cli-utils](https://github.com/kubernetes-sigs/cli-utils/tree/master/pkg/kstatus)\n\nWith the `depends-on` annotation, Config Sync not only applies objects in the\norder that you want, it also verifies\nthat the dependency object is reconciled before applying the dependent object.\n\nIf the dependecy object does not reconcile within the default reconcile timeout of 5 minutes, Config Sync will not apply the dependent object until next sync period. You can override the default reconcile timeout by setting [`spec.override.reconcileTimeout`](/kubernetes-engine/enterprise/config-sync/docs/reference/rootsync-reposync-fields#reconcile-timeout).\n\nAdd the `depends-on` annotation to an object\n--------------------------------------------\n\nTo specify a dependency, add the `config.kubernetes.io/depends-on` annotation\non the dependent object with a value that references the\ndependency objects.\n\nFor the Wordpress example, the annotation in Wordpress Deployment\nresembles the following: \n\n # deployment.yaml\n apiVersion: apps/v1\n kind: Deployment\n metadata:\n name: wordpress\n namespace: default\n labels:\n app: wordpress\n annotations:\n config.kubernetes.io/depends-on: apps/namespaces/default/StatefulSet/wordpress-mysql\n\nWhen Config Sync applies the objects, it first applies the dependency, the\nobject `wordpress-mysql` StatefulSet. When the dependency has been reconciled,\nConfig Sync applies the dependent, the\n`wordpress` Deployment.\n\nObject references\n-----------------\n\nObject references use the following syntax:\n\n- For namespaced objects:\n\n \u003cvar translate=\"no\"\u003eGROUP\u003c/var\u003e/namespaces/\u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e/\u003cvar translate=\"no\"\u003eKIND\u003c/var\u003e/\u003cvar translate=\"no\"\u003eNAME\u003c/var\u003e\n\n- For cluster-scoped objects:\n\n \u003cvar translate=\"no\"\u003eGROUP\u003c/var\u003e/\u003cvar translate=\"no\"\u003eKIND\u003c/var\u003e/\u003cvar translate=\"no\"\u003eNAME\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eGROUP\u003c/var\u003e: The group of the dependency object.\n - \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e: The namespace of the namespace-scoped dependency object.\n - \u003cvar translate=\"no\"\u003eKIND\u003c/var\u003e: The kind of the dependency object. This field is case sensitive. For example, use \"Pod\" instead of \"pod\".\n - \u003cvar translate=\"no\"\u003eNAME\u003c/var\u003e: The name of the dependency object.\n\nFor objects in the core group,\nthe empty string is used instead, for example `/namespaces/test/Pod/pod-a`.\n\nUse `,` to separate multiple object references, for example\n`/namespaces/test/Pod/pod-a,/namespaces/test/Pod/pod-b`."]]
