Un nombre alternativo del sujeto (SAN) es una función de los certificados SSL que te permite definir los nombres de dominio y los subdominios protegidos por un certificado. En un clúster de Google Distributed Cloud, las SANs predeterminadas del certificado del servidor de la API de Kubernetes incluyen las direcciones IP y VIP de los nodos del plano de control y los nombres de DNS de Kubernetes. Con la función de SANs adicionales del certificado de servidor de API personalizado, puedes añadir dominios, subdominios y direcciones IP adicionales como SANs al certificado de servidor de API de Kubernetes del clúster.
Para especificar SANs personalizados para el certificado del servidor de la API, usa el campo
controlPlane.apiServerCertExtraSANs
en la especificación de configuración del clúster. Este campo acepta una lista de nombres de dominio
y direcciones IP. Este campo es opcional y mutable. Puede añadir este campo y actualizarlo al crear un clúster o en cualquier momento posterior.
...
kind: Cluster
metadata:
name: sample001
namespace: cluster-sample001
spec:
type: user
...
controlPlane:
apiServerCertExtraSANs:
- "demo-dns.example.com"
- "sample-dns.com"
nodePoolSpec:
nodes:
- address: 10.200.0.20
clusterNetwork:
...
Añadir dominios durante la creación del clúster
Cuando añades SANs adicionales al crear un clúster, el certificado del servidor de la API de Kubernetes incluye los dominios y las direcciones IP adicionales especificados cuando el clúster está disponible.
Añadir o actualizar dominios de un clúster
Como el campo apiServerCertExtraSANs es mutable, puede añadir o actualizar el campo en cualquier momento para los clústeres que ya tenga. Cuando modificas el campo apiServerCertExtraSANs del clúster, se activan las siguientes actividades:
Los controladores del clúster de Google Distributed Cloud regeneran el certificado del servidor de la API para incluir los dominios adicionales modificados.
Los controladores del clúster reinician el servidor de la API para volver a cargar el nuevo certificado.
Los nuevos valores de
apiServerCertExtraSANsse verifican mediante un webhook para asegurarse de que cumplen las convenciones de nombres de dominio de la RFC 1035.El grupo de nodos del plano de control entra en estado de conciliación.
Control Plane Node Pool Status: Anthos Bare Metal Version: 1.28.0-gke.435 Anthos Bare Metal Versions: 1.28.0-gke.435: 3 Conditions: ... Last Transition Time: 2023-11-15T18:23:49Z Observed Generation: 1 Reason: Reconciling Status: True Type: ReconcilingEl grupo de nodos estará listo cuando el cambio se propague a los servidores de la API de Kubernetes de cada nodo del plano de control.
Control Plane Node Pool Status: Anthos Bare Metal Version: 1.28.0-gke.435 Anthos Bare Metal Versions: 1.28.0-gke.435: 3 Conditions: . . . Last Transition Time: 2023-11-15T18:32:25Z Observed Generation: 1 Reason: ReconciliationCompleted Status: False Type: Reconciling
Es posible que experimentes un tiempo de inactividad al actualizar el campo extra_sans del certificado del servidor de la API en un clúster en ejecución:
En los clústeres de alta disponibilidad, las instancias del servidor de la API se reinician de forma secuencial. Puedes seguir interactuando con el clúster durante la actualización del certificado, ya que el balanceador de carga distribuye las solicitudes a cada servidor de la API. Sin embargo, es posible que veas una respuesta que indique que el servidor de la API se está cerrando. Si ves esta respuesta, vuelve a intentar enviar la solicitud.
En los clústeres que no son de alta disponibilidad, puede haber una breve interrupción de aproximadamente un minuto mientras se reinicia un servidor de API para volver a cargar el nuevo certificado.
El cambio tarda entre 5 y 20 minutos en propagarse a todos los servidores de la API, en función del número de nodos del plano de control del clúster y de la carga del clúster.