- Navios
- 23 de agosto de 2026 às 02:40 UTC
- Autor
- Kamo
- Enviar
- 9adb653
Uma nova organização precisa de um certificado para todos os onze dos seus anfitriões, e cada um é um certificado de certificado-gerente separado. O laço esperou por cada host para ficar pronto antes de aplicar a próxima especificação, e reconstruído o TLSStore depois de cada um, então os anfitriões apareceram com 105 segundos de diferença. Cerca de vinte minutos do fim ao fim. cert-manager foi sempre feliz em executar o ordens simultaneamente; nada aqui necessário para serializá-los. As especificações estão agora aplicado em uma passagem e o lote é servido em conjunto, chamada API única, publicando cada host para o TLSStore como ele pousa. A maioria dos 105 segundos foi update tls store(): ele gerou openssl duas vezes por certificado em 200+ tls segredos, em cada 60s loop e novamente após cada emissão. Expiração e SANs agora vêm de uma chamada aberta cada, em cache contra o recurso do SegredoVersion -- que muda sempre que o bytes de certificado fazem -- então segredos inalterados nunca são re-parsed. Expiração é ainda avaliado contra o relógio em cada leitura; somente o parse é armazenado em cache. As ~40 linhas de salto imutáveis cada varredura impressas são registradas uma vez, então o A linha que diz qual hospedeiro está sendo emitido não está mais enterrada. Também pare de anunciar uma máquina que nunca teve um certificado como 'RENEW: certificado expirado ou expirado' -- is k8s cert expired fqdn() responde verdadeiro para um segredo perdido, que durante uma falha aponta o investigação num problema de renovação que não existe.