Agrega dominios al certificado del servidor de la API
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Un nombre alternativo de la entidad (SAN) es una función de los certificados SSL que te permite
definir los nombres de dominio y subdominios que están protegidos por un certificado. En un clúster de Google Distributed Cloud, las SAN predeterminadas para el 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 SAN adicionales del certificado de servidor de API personalizado,
puedes agregar dominios, subdominios y direcciones IP adicionales como SAN al
certificado de servidor de la API de Kubernetes del clúster.
Para especificar SAN 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 toma una lista de nombres de dominio y direcciones IP. Este campo es opcional y mutable. Puedes agregar este campo y actualizarlo cuando creas un clúster o en cualquier momento después.
Cuando agregas SAN adicionales cuando creas un clúster, el certificado del servidor de la API de Kubernetes incluye los dominios y las direcciones IP especificados adicionales cuando el clúster está disponible.
Agrega o actualiza dominios para un clúster existente
Como el campo apiServerCertExtraSANs es mutable, puedes agregarlo o actualizarlo
en cualquier momento para los clústeres existentes. Cuando modificas el campo apiServerCertExtraSANs en el clúster, se activan las siguientes actividades:
Los controladores de clúster de Google Distributed Cloud vuelven a generar el certificado del servidor de API para incluir los dominios adicionales modificados.
Los controladores del clúster reinician el servidor de la API para volver a cargar el certificado nuevo.
El grupo de nodos del plano de control entra en un estado de conciliación.
Control Plane Node Pool Status:Anthos Bare Metal Version:1.28.0-gke.435Anthos Bare Metal Versions:1.28.0-gke.435:3Conditions:...Last Transition Time:2023-11-15T18:23:49ZObserved Generation:1Reason:ReconcilingStatus:TrueType:Reconciling
El grupo de nodos estará listo después de que el cambio se propague a los servidores de la API de Kubernetes en cada nodo del plano de control.
Control Plane Node Pool Status:Anthos Bare Metal Version:1.28.0-gke.435Anthos Bare Metal Versions:1.28.0-gke.435:3Conditions:. . .Last Transition Time:2023-11-15T18:32:25ZObserved Generation:1Reason:ReconciliationCompletedStatus:FalseType:Reconciling
Es posible que experimentes un tiempo de inactividad cuando actualices el campo de SAN adicionales del certificado del servidor de la API en un clúster en ejecución:
En los clústeres de alta disponibilidad (HA), las instancias del servidor de la API se reinician de forma secuencial. Puedes interactuar con el clúster durante la actualización del certificado, ya que el balanceador de cargas 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 la solicitud.
En los clústeres que no tienen alta disponibilidad, es posible que haya una breve interrupción de aproximadamente un minuto mientras se reinicia un servidor de la API para volver a cargar el certificado nuevo.
El cambio tarda entre 5 y 20 minutos en propagarse a todos los servidores de la API, según la
cantidad de nodos del plano de control en el clúster y la carga del clúster.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-01 (UTC)"],[],[],null,["A subject alternative name (SAN) is a feature of SSL certificates that lets you\ndefine the domain names and subdomains that are secured by a certificate. On an\nGoogle Distributed Cloud cluster, the default SANs for the Kubernetes API server\ncertificate include the IP and VIP addresses of the control plane nodes and the\nKubernetes DNS names. With the custom API server certificate extra SANs feature,\nyou can add additional domains, subdomains, and IP addresses as SANs to the\nKubernetes API server certificate for the cluster.\n\nTo specify custom SANs for the API server certificate, you use the\n[`controlPlane.apiServerCertExtraSANs`](/kubernetes-engine/distributed-cloud/bare-metal/docs/reference/cluster-config-ref#controlplane-apiservercertextrasans)\nfield in the cluster configuration spec. This field takes a list of domain names\nand IP addresses. This field is optional and mutable. You can add this field and\nupdate it when you create a cluster or any time after. \n\n ...\n kind: Cluster\n metadata:\n name: sample001\n namespace: cluster-sample001\n spec:\n type: user\n ...\n controlPlane:apiServerCertExtraSANs:\n - \"demo-dns.example.com\"\n - \"sample-dns.com\"\n nodePoolSpec:\n nodes:\n - address: 10.200.0.20\n clusterNetwork:\n ...\n\nAdd domains during cluster creation\n\nWhen you add extra SANs when you create a cluster, the Kubernetes API server\ncertificate includes the additional specified domains and IP addresses when the\ncluster becomes available.\n\nAdd or update domains for an existing cluster\n\nBecause the `apiServerCertExtraSANs` field is mutable, you can add or update the\nfield at any time for existing clusters. When you modify the\n`apiServerCertExtraSANs` field in the cluster, it triggers the following\nactivities:\n\n- The Google Distributed Cloud cluster controllers regenerate the API server\n certificate to include the modified extra domains.\n\n- The cluster controllers restart the API server to reload the new\n certificate.\n\n- The new values of `apiServerCertExtraSANs` are verified by a webhook to\n ensure that they conform to the [RFC 1035 domain name\n conventions](https://datatracker.ietf.org/doc/html/rfc1035).\n\n- The control plane node pool enters a reconciling state.\n\n Control Plane Node Pool Status:\n Anthos Bare Metal Version: 1.28.0-gke.435\n Anthos Bare Metal Versions:\n 1.28.0-gke.435: 3\n Conditions:\n ...\n Last Transition Time: 2023-11-15T18:23:49Z\n Observed Generation: 1Reason: Reconciling\n Status: True\n Type: Reconciling\n\n- The node pool becomes ready after the change propagates to the Kubernetes\n API servers on each control plane node.\n\n Control Plane Node Pool Status:\n Anthos Bare Metal Version: 1.28.0-gke.435\n Anthos Bare Metal Versions:\n 1.28.0-gke.435: 3\n Conditions:\n . . .\n Last Transition Time: 2023-11-15T18:32:25Z\n Observed Generation: 1Reason: ReconciliationCompleted\n Status: False\n Type: Reconciling\n\nYou might experience downtime when updating the API server certificate extra\nSANs field on a running cluster:\n\n- On high availability (HA) clusters, API server instances restart\n sequentially. You can still interact with the cluster during the certificate\n update, because the load balancer distributes requests to each API server.\n However, you might see a response indicating that the API server is shutting\n down. If you see this response, retry the request.\n\n- On non-HA clusters, there might be a brief outage of about one minute while\n an API server restarts to reload the new certificate.\n\nThe change takes 5-20 minutes to propagate to all API servers, depending on the\nnumber of control plane nodes in the cluster and the load of the cluster."]]
