Esta página mostra como resolver problemas com webhooks problemáticos ou não seguros no Google Distributed Cloud.
Tipos de webhooks problemáticos
Webhooks de admissão, ou webhooks no Kubernetes, são um tipo de
controlador de admissão
que pode ser usado em clusters do Kubernetes para validar ou modificar solicitações para o
plano de controle antes que elas sejam mantidas. É comum que aplicativos de terceiros usem webhooks que operam em recursos e namespaces críticos para o sistema. Os webhooks configurados incorretamente podem afetar o desempenho e a confiabilidade
do plano de controle. Por exemplo, um webhook configurado incorretamente,
criado por um aplicativo de terceiros, pode impedir que o Google Distributed Cloud crie e
modifique recursos no namespace kube-system gerenciado, o que pode prejudicar
a funcionalidade do cluster.
Os webhooks problemáticos incluem os seguintes tipos:
- Webhooks que funcionam, mas não têm endpoints disponíveis. Siga as instruções para verificar os webhooks sem endpoints disponíveis.
Webhooks considerados não seguros quando operam em recursos e namespaces críticos do sistema.
Os webhooks abaixo são considerados não seguros:
- Webhooks que interceptam pods e leases no namespace
kube-system. - Webhooks que interceptam leases no namespace
kube-node-lease. - Webhooks que interceptam os recursos
Nodes,TokenReviews,SubjectAccessReviewseCertificateSigningRequests.
Siga as instruções para verificar os webhooks que são considerados não seguros.
- Webhooks que interceptam pods e leases no namespace
Webhooks que não têm endpoints disponíveis
Se um webhook não tiver endpoints disponíveis, o serviço que apoia o endpoint do webhook terá um ou mais pods que não estarão em execução. Para disponibilizar os endpoints do webhook, siga as instruções para encontrar e resolver problemas de pods do serviço que dá suporte a eles:
Encontre os pods de exibição do serviço associado ao webhook. Execute o seguinte comando para descrever o serviço:
kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACESubstitua:
- SERVICE_NAME pelo nome do serviço.
- SERVICE_NAMESPACE pelo nome do namespace.
Se você não encontrar o nome do serviço listado no webhook, o endpoint indisponível poderá ser causado por uma incompatibilidade entre o nome listado na configuração e o nome real do serviço. Para corrigir a disponibilidade do endpoint, atualize o nome do serviço na configuração do webhook para corresponder ao objeto de serviço correto.
Inspecione os pods de exibição em busca desse serviço. Identifique quais pods não estão em execução listando a implantação:
kubectl get deployment -n SERVICE_NAMESPACETambém é possível executar o seguinte comando para listar os pods:
kubectl get pods -n SERVICE_NAMESPACE -o wideInspecione os registros de pods que não estejam em execução para saber por que eles não estão em execução.
Webhooks considerados não seguros
Se um webhook interceptar recursos em namespaces gerenciados pelo sistema, a recomendação será a atualização para evitar a interceptação desses recursos.
Inspecione a configuração do webhook. Execute o seguinte comando
kubectlpara conferir a configuração do webhook:kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yamlSubstitua CONFIGURATION_NAME pelo nome da configuração do webhook.
Se esse comando não retornar nada, execute o comando novamente, substituindo
validatingwebhookconfigurationspormutatingwebhookconfigurations.Na seção
webhooksda saída, um ou mais webhooks são listados.Edite a configuração, dependendo do motivo pelo qual o webhook é considerado não seguro:
Excluir namespaces kube-system e kube-node-lease
Um webhook não será considerado seguro se
scopefor*ou se o escopo forNamespacede uma das seguintes condições for verdadeira:A condição
operatoréNotIn, evaluesomitekube-systemekube-node-lease, como no exemplo a seguir:webhooks: - admissionReviewVersions: ... namespaceSelector: matchExpressions: - key: kubernetes.io/metadata.name operator: NotIn values: - blue-system # add 'kube-system' and 'kube-node-lease' if `NotIn` objectSelector: {} rules: - apiGroups: ... scope: '*' # 'Namespaced' sideEffects: None timeoutSeconds: 3Verifique se
scopeestá definido comoNamespaced, não*, para que o webhook opere apenas em namespaces específicos. Verifique seoperatoréNotIn,kube-systemekube-node-leaseestão incluídos emvalues.A condição
operatoréInevaluesincluikube-systemekube-node-lease, como no exemplo a seguir:namespaceSelector: matchExpressions: - key: kubernetes.io/metadata.name operator: In values: - blue-system - kube-system # remove as operator is `In` - kube-node-lease # remove as operator is `In`Verifique se
scopeestá definido comoNamespaced, não*, para que o webhook opere apenas em namespaces específicos. Verifique seoperatoréIn,kube-systemekube-node-leasenão estão incluídos emvalues.
Excluir recursos correspondentes
Um webhook também é considerado não seguro quando
nodes,tokenreviews,subjectaccessreviewsoucertificatesigningrequestsestão listados em recursos, como no seguinte exemplo:- admissionReviewVersions: ... resources: - 'pods' # keep, remove everything else - 'nodes' - 'tokenreviews' - 'subjectacessreviews' - 'certificatesigningrequests' scope: '*' sideEffects: None timeoutSeconds: 3Remova
nodes,tokenreviews,subjectaccessreviewsecertificatesigningrequestsda seção de recursos.
A seguir
Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.
Consulte também Receber suporte para mais informações sobre recursos de suporte, incluindo:
- Requisitos para abrir um caso de suporte.
- Ferramentas para ajudar você a resolver problemas, como registros e métricas.
- Componentes, versões e recursos compatíveis do Google Distributed Cloud para VMware (somente software).