구성 커넥터가 Google Cloud에서 리소스를 만들 때 사양에 지정되지 않은 필드는 읽을 수 없는 경우가 아닌 이상 API에서 값을 가져옵니다. (예를 들어 GET HTTP 요청을 사용할 수 없습니다.)
이 경우 Kubernetes는 이 값의 출처가 아니므로 이 필드는 '외부 관리'로 간주됩니다.
서버 측 적용 동작
서버 측 적용이 리소스에 대해 사용 설정된 경우 객체의 외부에서 관리되는 필드의 값이 기본 Google Cloud 리소스와 일치하도록 계속 업데이트됩니다.
적용된 구성의 사양에 필드 값이 있는 경우 해당 필드는 외부에서 관리되지 않습니다.
필드가 삭제된 경우 필드가 외부에서 관리됩니다.
서버 측 미적용 동작
서버 측 적용을 사용 설정하지 않으면 리소스 사양의 지정되지 않은 필드가 Google Cloud API에서 읽은 값으로 채워지고 구성 커넥터는 초기에 채워진 값을 적용합니다.
예를 들어 사용자가 사양에서 bar 값을 설정하지 않고 리소스 구성을 적용하는 경우:
spec:foo:"foo"
bar 필드의 값이 Google Cloud API에서 baz이면 api-server의 리소스가 해당 값으로 채워집니다.
# object in the api-serverspec:foo:"foo"bar:"baz"# populated by first reconciliation
bar가 이제 baz-2이 되도록 Google Cloud 리소스를 직접 수정하면 Google Cloud API가 처음에 리소스 사양 baz에 채워진 값으로 수정됩니다.
# object in the api-serverspec:foo:"foo"bar:"baz"# still the originally populated value, and overrides the Google Cloud value
리소스 사양의 목록 필드 동작
구성 커넥터의 기술적 제한으로 인해 리소스 구성의 목록 필드는 기본적으로 외부에서 관리할 수 없습니다. 즉, 필드가 원본 리소스 구성에 지정되지 않은 경우에도 구성 커넥터는 항상 리소스 사양의 목록 필드에 대한 소유권을 갖습니다.
리소스 사양이 적용되면 구성 커넥터는 Google Cloud API에서 목록 필드의 값을 읽고 이 초기 값을 정보 소스 및 원하는 상태로 처리합니다. 해당 목록 필드의 값이 구성 커넥터 외부에서 수정되면 구성 커넥터가 이 값을 다시 변경하려고 시도하지만 이는 바람직하지 않을 수 있습니다.
이 제한사항을 우회하고 목록 필드를 외부에서 관리할 수 있게 하려면 cnrm.cloud.google.com/state-into-spec 주석을 사용합니다. 이 주석은 모든 리소스에 지원되지 않습니다. 리소스에서 주석을 지원하는지 확인하려면 해당 리소스 참조 페이지를 확인하세요.
state-into-spec의 값을 absent로 설정하면 리소스 구성에 목록 필드를 지정하지 않은 경우 구성 커넥터가 목록 필드를 무시합니다. 이렇게 하면 리소스의 목록 필드를 외부에서 관리할 수 있습니다.
주의사항
구성 커넥터에서 관리되고 외부 서비스에서 자동으로 업데이트되는 필드는 기본 API에서 끊임 없는 업데이트를 유발할 수 있습니다. 기본 API에 자동 확장 처리 또는 자동 업데이트 필드가 포함된 경우에 이러한 문제가 발생할 수 있습니다. 리소스에 대해 서버 측 적용을 사용 설정하고 적용 시 구성 파일 외부에 필드를 두어 이러한 필드가 외부적으로 관리되는 것으로 처리되도록 해야 합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2024-12-21(UTC)"],[[["\u003cp\u003eConfig Connector considers fields left unspecified in a resource's spec as "externally managed," meaning Kubernetes is not the source of truth for those values.\u003c/p\u003e\n"],["\u003cp\u003eWhen server-side apply is enabled, externally managed fields are continuously updated to mirror the values in the underlying Google Cloud resource.\u003c/p\u003e\n"],["\u003cp\u003eWithout server-side apply, unspecified fields are initially populated with values from the Google Cloud API, and Config Connector enforces these initially populated values, even overriding subsequent changes made directly to Google Cloud.\u003c/p\u003e\n"],["\u003cp\u003eList fields in resource specs are always managed by Config Connector by default, but they can be managed externally by using the \u003ccode\u003ecnrm.cloud.google.com/state-into-spec: absent\u003c/code\u003e annotation if supported by the resource.\u003c/p\u003e\n"],["\u003cp\u003eFields that are both managed by Config Connector and automatically updated by external services can cause constant updates, so it is recommended that the fields be treated as externally managed by enabling server-side apply.\u003c/p\u003e\n"]]],[],null,["# Manage fields externally\n========================\n\n*** ** * ** ***\n\n| **Caution:** For CRDs added in [version 1.114.0 and later](https://github.com/GoogleCloudPlatform/k8s-config-connector/tree/master/crds), externally managed fields are not populated by default.\n\nWhen Config Connector creates a resource on Google Cloud, fields left\nunspecified in the spec take on values from the API unless they are not readable\n(for example, are not available by using a GET HTTP request).\n\nIn this case, the field is considered \"externally managed\", as Kubernetes is not\nthe source of truth for this value.\n\nBehavior with server-side apply\n-------------------------------\n\nIf\n[server-side apply](https://kubernetes.io/docs/reference/using-api/api-concepts/#server-side-apply)\nis enabled for the resource, the values of externally managed fields in the\nobject is updated continuously to match the underlying Google Cloud\nresource.\n\nIf a value is present for a field in the spec in the applied configuration, the\nfield is not externally managed.\n\nIf the field is removed, the field is externally managed.\n| **Note:** For fields which are lists, this behavior does not hold, and instead follows the behavior without server-side apply [in the following section](#behavior-without-server-side-apply).\n\nBehavior without server-side apply\n----------------------------------\n\nIf server-side apply is not enabled, unspecified fields in the resource spec\nare populated with the value read from the Google Cloud API, and\nConfig Connector enforces those initially populated values.\n\nAs an example: if the user applies a resource configuration without setting a\nvalue for `bar` in the spec: \n\n spec:\n foo: \"foo\"\n\nIf the value of the `bar` field is `baz` in the Google Cloud API, the\nresource in the\n[api-server](https://kubernetes.io/docs/concepts/overview/components/#kube-apiserver)\nis populated to that value: \n\n # object in the api-server\n spec:\n foo: \"foo\"\n bar: \"baz\" # populated by first reconciliation\n\nIf the Google Cloud resource is modified directly such that `bar` is now\n`baz-2`, the Google Cloud API is corrected to the value that was\ninitially populated in the resource spec: `baz`: \n\n # object in the api-server\n spec:\n foo: \"foo\"\n bar: \"baz\" # still the originally populated value, and overrides the Google Cloud value\n\nBehavior for list fields in resource spec\n-----------------------------------------\n\nDue to technical limitation in Config Connector, list fields in your resource\nconfiguration cannot be managed externally by default. This means\nConfig Connector always takes ownership of list fields in the resource spec,\neven when the field is not specified in your original resource configuration.\n\nAt the time when a resource spec is applied, Config Connector reads the\nvalue of list fields from the Google Cloud API and treats this initial\nvalue as source of truth and desired state. If the value in that list field is\nmodified outside of Config Connector, Config Connector tries to change it\nback, which might not be desired.\n\nTo bypass this limitation and let list fields be managed externally,\nuse the `cnrm.cloud.google.com/state-into-spec` annotation. This\nannotation is not supported for all resources. To see if your\nresource supports the annotation, check the corresponding\n[resource reference page](/config-connector/docs/reference/resources). \n\n metadata:\n annotations:\n cnrm.cloud.google.com/state-into-spec: absent\n\nBy setting value of `state-into-spec` as `absent`, Config Connector ignores\nlist fields if they are not specified in your resource configuration. This leaves\nlist fields in the resource to be managed externally.\n\nCaveats\n-------\n\nFields that are both managed by Config Connector and automatically updated by\nexternal services can trigger endless updating on the underlying API. This can\nhappen if the underlying API has autoscaling or autoupdating fields. Ensure that\nthese fields are treated as externally managed by enabling server-side apply for\nthe resource and leaving the field out of your config file when applying."]]
