[[["容易理解","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 (世界標準時間)。"],[[["\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."]]
