Ignore campos não especificados
Esta página explica o comportamento de preenchimento predefinido dos campos spec
e como alterar o comportamento predefinido de Merge
para o comportamento recomendado Absent
. Esta página pode não ser aplicável se estiver a usar um CRD adicionado na versão 1.114.0 e posterior, porque esses CRDs usam apenas o comportamento Absent
. Para ver uma lista de CRDs que suportam Merge
, consulte a secção CRDs com suporte do Merge
desta página.
spec
comportamentos de preenchimento de campos
Quando o Config Connector cria um recurso, os campos não especificados na especificação do recurso do Kubernetes podem ter dois comportamentos de preenchimento predefinidos diferentes: Absent
e Merge
.
Ausente
Absent
é o comportamento recomendado. O Config Connector não preenche nenhum campo não especificado na especificação.
Para CRDs adicionados na versão 1.114.0 e
posterior,
o comportamento de preenchimento predefinido é Absent
. Este é também o único comportamento de preenchimento suportado por esses CRDs. O valor da anotação cnrm.cloud.google.com/state-into-spec
é absent
nestes CRs de recursos.
Unir
Merge
é um comportamento não suportado em CRDs adicionados na versão 1.114.0 e posteriores. Os campos spec
assumem valores da API após uma conciliação bem-sucedida, a menos que não sejam legíveis. Pode encontrar mais detalhes em Faça a gestão dos campos externamente.
Para CRDs suportados na versão
1.113.0
e anteriores do Config Connector, o comportamento de preenchimento predefinido é Merge
. Para ver uma lista de CRDs que
suportam Merge
, consulte a secção CRDs com suporte do Merge
desta página. O valor predefinido da anotação cnrm.cloud.google.com/state-into-spec
é merge
nestes CRs de recursos. Também pode configurar o comportamento de preenchimento para Absent
seguir as
instruções em Ignorar o preenchimento de campos não especificados no
spec.
Por predefinição, nestes CRs de recursos, os campos que não foram especificados no YAML original aparecem sempre na especificação do CR. Isto significa que, quando executa kubectl get <resource kind> <resource name> -oyaml
, muitos campos na especificação não estão no YAML aplicado.
Por exemplo, suponha que o esquema CRD lhe permite especificar dois campos denominados foo
e bar
na especificação, enquanto o ficheiro YAML aplicado tem apenas foo
especificado:
spec:
foo: "foo"
Vai reparar noutro campo denominado bar
no CR se o YAML for aplicado com êxito e o recurso estiver UpToDate:
spec:
foo: "foo"
bar: "bar"
Devido à complexidade da interação entre o Config Connector e as APIs, é recomendável alterar este comportamento predefinido e ignorar o preenchimento da especificação de recursos do Kubernetes com campos não especificados.Google Cloud
Ignorar o preenchimento de campos não especificados na especificação
Pode ignorar o preenchimento de campos não especificados na especificação para CRDs suportados na versão 1.113.0 do Config Connector e anteriores de qualquer uma das seguintes formas:
- Configure a substituição ao nível do cluster ou do espaço de nomes para ser
stateIntoSpec
Absent
. - Especifique o valor da anotação
cnrm.cloud.google.com/state-into-spec
comoabsent
para o recurso.
Configure a substituição ao nível do cluster ou do espaço de nomes stateIntoSpec
Quando instala o Config Connector ou atualiza a instalação do Config Connector,
pode configurar a stateIntoSpec
substituição
ao nível do cluster ou do espaço de nomes para ser Absent
no CR ConfigConnector ou no CR ConfigConnectorContext.
spec:
stateIntoSpec: Absent
Isto faz com que os campos Absent
sejam o comportamento de preenchimento predefinido para quaisquer novos recursos criados no cluster ou no espaço de nomes quando não especifica a anotação cnrm.cloud.google.com/state-into-spec
nos ficheiros YAML dos novos recursos.spec
Significa que o Config Connector vai ignorar o preenchimento de campos não especificados na especificação de recursos do Kubernetes para estes recursos.
O campo stateIntoSpec
não tem um valor predefinido. O Config Connector determina o comportamento de preenchimento dos campos spec
com base no valor da anotação cnrm.cloud.google.com/state-into-spec
e segue a lógica abaixo para determinar o valor da anotação:
- Use o valor da anotação
cnrm.cloud.google.com/state-into-spec
diretamente se for especificado e válido. - Se a anotação não estiver especificada, use o valor correspondente do campo
stateIntoSpec
no CR ConfigConnectorContext. - Se o CR ConfigConnectorContext não existir ou o campo
stateIntoSpec
não estiver especificado, use o valor correspondente do campostateIntoSpec
no CR ConfigConnector. - Se o CR do ConfigConnector não existir ou o campo
stateIntoSpec
não for especificado, use o comportamento predefinido com base no CRD descrito nosspec
comportamentos de preenchimento de campos.
Tenha em atenção que o único comportamento de preenchimento que os CRDs adicionados na versão 1.114.0 e
posteriores
seguem é Absent
, independentemente da anotação cnrm.cloud.google.com/state-into-spec
ou dos campos stateIntoSpec
no CR do ConfigConnector ou no CR do ConfigConnectorContext.
Se já tiver criado o recurso, mas quiser alterar o comportamento de preenchimento dos campos spec
para Absent
, deve:
Certifique-se de que a substituição ao nível do cluster ou do espaço de nomes é
stateIntoSpec
Absent
no CR do ConfigConnector ou no CR do ConfigConnectorContext.Abandone e adquira o recurso. Certifique-se de que a configuração YAML usada para a aquisição não tem a anotação
cnrm.cloud.google.com/state-into-spec
.
Especifique a anotação cnrm.cloud.google.com/state-into-spec
ao nível do recurso
Quando criar o ficheiro YAML, pode especificar o valor da anotação cnrm.cloud.google.com/state-into-spec
como absent
. Isto ignora o preenchimento de campos não especificados na especificação de recursos do Kubernetes:
metadata:
annotations:
cnrm.cloud.google.com/state-into-spec: absent
Esta anotação tem um valor predefinido de merge
se não for especificado, o que significa que o Config Connector preenche todos os campos não especificados em spec. Esta anotação é imutável, o que significa que não pode atualizar o valor de anotação de um recurso do Config Connector existente.
Se já tiver criado o recurso, mas quiser alterar o valor desta anotação para um comportamento de preenchimento diferente, tem de seguir estes passos:
Edite e adicione a anotação
cnrm.cloud.google.com/deletion-policy: abandon
ao recurso do Kubernetes existente para garantir que a eliminação no passo seguinte não elimina o recurso Google Cloud subjacente.Elimine o recurso do cluster do Kubernetes.
Adicione a anotação
cnrm.cloud.google.com/state-into-spec: absent
ao YAML do recurso.(Opcional) Remova
cnrm.cloud.google.com/deletion-policy: abandon
do YAML.Aplique o YAML atualizado.
Para explicar melhor a diferença introduzida por esta anotação, suponha que existe uma especificação com o seguinte esquema:
foo1: string
foo2: string
bars:
- bar:
br1: string
br2: string
barz:
bz1: string
bz2: string
Suponha também que especificou a especificação no seu YAML da seguinte forma:
spec:
foo1: "foo1"
bars:
- br1: "1_br1"
- br1: "2_br1"
barz:
bz1: "bz1"
Por predefinição, a especificação preenchida no recurso do Kubernetes criado pode ser:
spec:
foo1: "foo1"
foo2: "foo2"
bars:
- br1: "1_br1"
br2: "1_br2"
- br1: "2_br1"
br2: "2_br2"
barz:
bz1: "bz1"
bz2: "bz2"
Por outro lado, se definir cnrm.cloud.google.com/state-into-spec: absent
, a especificação final
no recurso do Kubernetes criado será:
spec:
foo1: "foo1"
bars:
- br1: "1_br1"
- br1: "2_br1"
barz:
bz1: "bz1"
Quando usar o cnrm.cloud.google.com/state-into-spec: absent
Na maioria dos casos, é aconselhável definir cnrm.cloud.google.com/state-into-spec: absent
para obter o comportamento de preenchimento automático de Absent
para os campos spec
. Seguem-se os cenários mais comuns que beneficiam do comportamento de preenchimento automático.Absent
Faça a gestão de campos não especificados numa lista externamente
O Config Connector trata todos os campos de lista na especificação de recursos do Kubernetes como campos atómicos. Como resultado, por predefinição, a alteração feita a um subcampo na lista fora do Config Connector é revertida pelo Config Connector. No entanto, pode usar esta anotação para permitir que o Config Connector não faça a gestão dos subcampos na lista. Para mais informações, consulte o artigo Comportamento dos campos de listas na especificação de recursos.
Resolva conflitos entre ferramentas de gestão de configuração e o Config Connector
Se estiver a usar ferramentas de gestão de configuração como o Config Sync ou o Argo CD, pode notar um conflito entre a ferramenta de gestão de configuração e o Config Connector. Um exemplo é o erro KNV2005 explicado no guia de resolução de problemas. A causa principal destes tipos de problemas é que:
- O Config Connector preenche e define como predefinição os valores não especificados na lista na especificação. O
spec.bars[0].br2
é um exemplo. - As ferramentas de gestão de configuração e o Config Connector tratam os campos de lista como atómicos. Assim, o
spec.bars[0].br2
adicionado é tratado como uma derivação pelas ferramentas de gestão de configuração e é removido para corrigir odrift
.
Para resolver estes problemas, pode definir cnrm.cloud.google.com/state-into-spec:
absent
para que o Config Connector não adicione o campo não especificado
spec.bars[0].br2
à especificação.
Resolva problemas de simetria GET/PUT
A simetria GET/PUT refere-se a um princípio de criação na API REST. Especificamente, significa que, quando uma resposta GET é enviada como um pedido PUT para o mesmo URL, o resultado esperado é uma resposta HTTP 200 OK sem alteração no estado do recurso REST subjacente.
Os campos não especificados preenchidos pelo Config Connector na especificação do recurso do Kubernetes são o resultado de um pedido GET. Isto significa que, em futuras
conciliações,
o Config Connector pode enviar um pedido PUT/PATCH à
Google Cloud API subjacente, com estes valores de campos não especificados aprendidos com o pedido GET. Normalmente, isto não é um problema, mas é possível que algumas
Google Cloud APIs rejeitem o pedido PUT/PATCH devido a estes
valores de campos não especificados. No mesmo exemplo, o parâmetro spec.barz.bz2
com o valor "bz2" pode resultar num erro de cliente HTTP 400 ou noutras respostas inesperadas se a implementação da API violar o princípio da simetria GET/PUT.
Para evitar esta categoria de problemas, pode experimentar definir cnrm.cloud.google.com/state-into-spec: absent
e verificar se os erros durante a conciliação desaparecem.
Estado observado
Se precisar de definir cnrm.cloud.google.com/state-into-spec: absent
, mas a sua solução depender dos valores preenchidos de campos não especificados, verifique se estes campos existem em status.observedState
no esquema CRD. Se forem representados em status.observedState
, pode definir cnrm.cloud.google.com/state-into-spec: absent
e continuar a aceder aos valores dos campos não especificados após uma conciliação bem-sucedida.
O campo status.observedState
contém o estado em direto dos campos selecionados e observados do recurso que o Config Connector observou na última conciliação bem-sucedida. Os campos observados são selecionados se forem dependências de exemplos de utilização comuns e forem campos spec
calculados. Pode encontrar os campos observados nos esquemas CRD.
Se não conseguir encontrar os campos observados pretendidos, verifique se existe um problema ou abra um novo problema nos rastreadores de problemas públicos .
Tipos com suporte do Merge
Seguem-se todos os tipos de Config Connector que suportam o comportamento de preenchimento Merge
:
- AccessContextManagerAccessLevel
- AccessContextManagerAccessPolicy
- AccessContextManagerServicePerimeter
- AlloyDBBackup
- AlloyDBCluster
- AlloyDBUser
- ApigeeEnvironment
- ApigeeOrganization
- ArtifactRegistryRepository
- BigQueryDataset
- BigQueryJob
- BigQueryTable
- BigtableAppProfile
- BigtableGCPolicy
- BigtableInstance
- BigtableTable
- BillingBudgetsBudget
- BinaryAuthorizationAttestor
- BinaryAuthorizationPolicy
- CertificateManagerCertificate
- CertificateManagerCertificateMap
- CertificateManagerCertificateMapEntry
- CloudBuildTrigger
- CloudFunctionsFunction
- CloudIdentityGroup
- CloudIdentityMembership
- CloudSchedulerJob
- ComputeAddress
- ComputeBackendBucket
- ComputeBackendService
- ComputeDisk
- ComputeExternalVPNGateway
- ComputeFirewall
- ComputeFirewallPolicy
- ComputeFirewallPolicyAssociation
- ComputeForwardingRule
- ComputeHTTPHealthCheck
- ComputeHTTPSHealthCheck
- ComputeHealthCheck
- ComputeImage
- ComputeInstance
- ComputeInstanceGroup
- ComputeInstanceGroupManager
- ComputeInstanceTemplate
- ComputeInterconnectAttachment
- ComputeNetwork
- ComputeNetworkEndpointGroup
- ComputeNetworkFirewallPolicy
- ComputeNetworkPeering
- ComputeNodeGroup
- ComputeNodeTemplate
- ComputePacketMirroring
- ComputeProjectMetadata
- ComputeRegionNetworkEndpointGroup
- ComputeReservation
- ComputeResourcePolicy
- ComputeRoute
- ComputeRouter
- ComputeRouterInterface
- ComputeRouterNAT
- ComputeRouterPeer
- ComputeSSLCertificate
- ComputeSSLPolicy
- ComputeSecurityPolicy
- ComputeServiceAttachment
- ComputeSharedVPCHostProject
- ComputeSharedVPCServiceProject
- ComputeSnapshot
- ComputeSubnetwork
- ComputeTargetGRPCProxy
- ComputeTargetHTTPProxy
- ComputeTargetHTTPSProxy
- ComputeTargetInstance
- ComputeTargetPool
- ComputeTargetSSLProxy
- ComputeTargetTCPProxy
- ComputeTargetVPNGateway
- ComputeURLMap
- ComputeVPNGateway
- ComputeVPNTunnel
- ConfigControllerInstance
- ContainerAnalysisNote
- ContainerAttachedCluster
- ContainerCluster
- ContainerNodePool
- DLPDeidentifyTemplate
- DLPInspectTemplate
- DLPJobTrigger
- DLPStoredInfoType
- DNSManagedZone
- DNSPolicy
- DNSRecordSet
- DataFusionInstance
- DataflowFlexTemplateJob
- DataflowJob
- DataprocAutoscalingPolicy
- DataprocCluster
- DataprocWorkflowTemplate
- EdgeContainerCluster
- EdgeContainerNodePool
- EdgeContainerVpnConnection
- EdgeNetworkNetwork
- EdgeNetworkSubnet
- EventarcTrigger
- FilestoreBackup
- FilestoreInstance
- FirestoreIndex
- Pasta
- GKEHubFeature
- GKEHubMembership
- IAMAccessBoundaryPolicy
- IAMAuditConfig
- IAMCustomRole
- IAMPartialPolicy
- IAMPolicy
- IAMPolicyMember
- IAMServiceAccount
- IAMServiceAccountKey
- IAMWorkforcePool
- IAMWorkforcePoolProvider
- IAMWorkloadIdentityPool
- IAMWorkloadIdentityPoolProvider
- IAPBrand
- IAPIdentityAwareProxyClient
- IdentityPlatformConfig
- IdentityPlatformOAuthIDPConfig
- IdentityPlatformTenant
- IdentityPlatformTenantOAuthIDPConfig
- KMSCryptoKey
- KMSKeyRing
- LoggingLogBucket
- LoggingLogExclusion
- LoggingLogSink
- LoggingLogView
- MemcacheInstance
- MonitoringAlertPolicy
- MonitoringGroup
- MonitoringMetricDescriptor
- MonitoringMonitoredProject
- MonitoringNotificationChannel
- MonitoringService
- MonitoringServiceLevelObjective
- MonitoringUptimeCheckConfig
- NetworkConnectivityHub
- NetworkConnectivitySpoke
- NetworkSecurityAuthorizationPolicy
- NetworkSecurityClientTLSPolicy
- NetworkSecurityServerTLSPolicy
- NetworkServicesEndpointPolicy
- NetworkServicesGRPCRoute
- NetworkServicesGateway
- NetworkServicesHTTPRoute
- NetworkServicesMesh
- NetworkServicesTCPRoute
- NetworkServicesTLSRoute
- OSConfigGuestPolicy
- OSConfigOSPolicyAssignment
- PrivateCACAPool
- PrivateCACertificate
- PrivateCACertificateAuthority
- PrivateCACertificateTemplate
- Projeto
- PubSubLiteReservation
- PubSubSchema
- PubSubSubscription
- PubSubTopic
- RecaptchaEnterpriseKey
- RedisInstance
- ResourceManagerLien
- ResourceManagerPolicy
- RunJob
- RunService
- SQLDatabase
- SQLSSLCert
- SQLUser
- SecretManagerSecret
- SecretManagerSecretVersion
- Serviço
- ServiceDirectoryEndpoint
- ServiceDirectoryNamespace
- ServiceDirectoryService
- ServiceIdentity
- ServiceNetworkingConnection
- SourceRepoRepository
- SpannerDatabase
- SpannerInstance
- StorageBucket
- StorageBucketAccessControl
- StorageDefaultObjectAccessControl
- StorageNotification
- StorageTransferJob
- VPCAccessConnector
Os seguintes tipos não suportam o comportamento de preenchimento Merge
a partir da versão correspondente:
Nome do tipo | Versão |
---|---|
LoggingLogMetric | 1.118.1 |