Config Connector が Google Cloud でリソースを作成すると、読み取り可能でない限り（つまり GET HTTP リクエストを使用して使用できないなど）、仕様で指定されていないフィールドは API から値を取得します。
この場合、Kubernetes がこの値の信頼できるソースではないため、フィールドは「外部管理」とみなされます。
サーバー側の適用に関する動作
リソースに対してサーバー側の適用が有効になっている場合、オブジェクト内の外部管理フィールドの値は、基盤となる Google Cloud リソースと一致するように継続的に更新されます。
適用された構成の仕様にフィールドの値が存在する場合、そのフィールドは外部で管理されません。
フィールドを削除すると、そのフィールドは外部で管理されます。
サーバー側での適用なしの動作
サーバー側の適用が有効になっていない場合、リソース仕様の未指定のフィールドには Google Cloud API から読み取られた値が入力され、Config Connector はそれらの初期入力値を適用します。
例: 仕様で bar の値を設定せずにユーザーがリソース構成を適用した場合:
spec:
foo: "foo"
Google Cloud API の bar フィールドの値が baz の場合、api-server のリソースにはその値が入力されます。
# object in the api-server
spec:
foo: "foo"
bar: "baz" # populated by first reconciliation
bar が baz-2 になるように Google Cloud リソースを直接変更した場合、リソース仕様で最初に入力された値（baz）に Google Cloud API が修正されます。
# object in the api-server
spec:
foo: "foo"
bar: "baz" # still the originally populated value, and overrides the Google Cloud value
リソース仕様のリスト フィールドの動作
Config Connector の技術的な制限により、リソース構成のリスト フィールドはデフォルトでは外部での管理ができません。つまり、元のリソース構成でフィールドが指定されていない場合でも、Config Connector は常にリソース仕様のリスト フィールドの所有権を取得します。
リソース仕様が適用されると、Config Connector は Google Cloud API からリスト フィールドの値を読み取り、この初期値を信頼できる情報源および望ましい状態として扱います。そのリスト フィールドの値が Config Connector の外部で変更された場合、Config Connector はそれを元に戻そうとしますが、この動作は求められていない場合もあります。
この制限を回避し、リスト フィールドを外部で管理できるようにするには、cnrm.cloud.google.com/state-into-spec アノテーションを使用します。このアノテーションは一部のリソースではサポートされていません。リソースがアノテーションをサポートしているかどうかを確認するには、対応するリソースのリファレンス ページをご覧ください。
metadata:
annotations:
cnrm.cloud.google.com/state-into-spec: absent
state-into-spec の値を absent に設定すると、リソース構成で指定されていない場合、Config Connector はリスト フィールドを無視します。これにより、リソース内のリスト フィールドは外部で管理されたままになります。
注意点
Config Connector によって管理されるフィールドと外部サービスによって自動的に更新されるフィールドが、基盤となる API で無期限の更新の原因となる場合があります。これは、基盤となる API に自動スケーリング フィールドまたは自動更新フィールドがある場合に発生する可能性があります。これらのフィールドは、リソースに対してサーバー側の適用を有効にし、適用時に構成ファイルを使用しないことで、外部管理として扱われるようにします。