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 はそれを元に戻そうとしますが、これは望ましくない場合もあります。
この制限をバイパスし、リスト フィールドを外部で管理できるようにするには、次のアノテーションを使用します。
metadata:
annotations:
cnrm.cloud.google.com/state-into-spec: absent
state-into-spec の値を absent に設定すると、リソース構成で指定されていない場合、Config Connector はリスト フィールドを無視します。これにより、リソース内のリスト フィールドは外部で管理されます。
注意点
Config Connector によって管理されるフィールドと外部サービスによって自動的に更新されるフィールドが、基盤となる API で無期限の更新の原因となる場合があります。これは、基盤となる API に自動スケーリング フィールドまたは自動更新フィールドがある場合に発生する可能性があります。これらのフィールドは、リソースに対してサーバー側の適用を有効にし、適用時に構成ファイルを使用しないことで、外部管理として扱われるようにします。