Ajouter des domaines au certificat du serveur d'API
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Un autre nom d'objet (SAN, Subject Alternative Name) est une fonctionnalité des certificats SSL qui vous permet de définir les noms de domaine et les sous-domaines sécurisés par un certificat. Sur un cluster Google Distributed Cloud, les SAN par défaut du certificat de serveur d'API Kubernetes incluent les adresses IP et les adresses IP virtuelles des nœuds du plan de contrôle, ainsi que les noms DNS de Kubernetes. Avec la fonctionnalité de SAN supplémentaires du certificat de serveur d'API personnalisé, vous pouvez ajouter des domaines, des sous-domaines et des adresses IP supplémentaires en tant que SAN au certificat de serveur d'API Kubernetes pour le cluster.
Pour spécifier des SAN personnalisés pour le certificat de serveur d'API, utilisez le champ controlPlane.apiServerCertExtraSANs dans la spécification de configuration du cluster. Ce champ prend une liste de noms de domaine et d'adresses IP. Ce champ est facultatif et modifiable. Vous pouvez ajouter ce champ et le mettre à jour lorsque vous créez un cluster ou à tout moment par la suite.
Ajouter des domaines lors de la création du cluster
Lorsque vous ajoutez des SAN supplémentaires lorsque vous créez un cluster, le certificat du serveur d'API Kubernetes inclut les domaines et adresses IP supplémentaires spécifiés lorsque le cluster devient disponible.
Ajouter ou mettre à jour des domaines pour un cluster existant
Le champ apiServerCertExtraSANs étant modifiable, vous pouvez l'ajouter ou le mettre à jour à tout moment pour les clusters existants. Lorsque vous modifiez le champ apiServerCertExtraSANs dans le cluster, les activités suivantes sont déclenchées :
Les contrôleurs de cluster Google Distributed Cloud génèrent à nouveau le certificat du serveur d'API pour inclure les domaines supplémentaires modifiés.
Les contrôleurs de cluster redémarrent le serveur d'API pour recharger le nouveau certificat.
Les nouvelles valeurs de apiServerCertExtraSANs sont validées par un webhook afin de s'assurer qu'elles sont conformes aux conventions des noms de domaine RFC 1035.
Le pool de nœuds du plan de contrôle passe à un état de rapprochement.
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
Le pool de nœuds est prêt une fois que le changement s'est propagé aux serveurs d'API Kubernetes sur chaque nœud du plan de contrôle.
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
Vous risquez de subir un temps d'arrêt lors de la mise à jour du champ "SAN supplémentaires" du certificat de serveur d'API sur un cluster en cours d'exécution :
Sur les clusters à haute disponibilité, les instances du serveur d'API redémarrent de manière séquentielle. Vous pouvez toujours interagir avec le cluster pendant la mise à jour du certificat, car l'équilibreur de charge distribue les requêtes à chaque serveur API.
Toutefois, il est possible qu'une réponse indiquant que le serveur d'API est en cours d'arrêt peut s'afficher. Si cette réponse s'affiche, relancez la requête.
Sur les clusters standards, une brève interruption d'environ une minute peut être nécessaire pendant qu'un serveur d'API redémarre pour recharger le nouveau certificat.
La propagation de la modification sur tous les serveurs d'API prend entre 5 et 20 minutes, en fonction du nombre de nœuds de plan de contrôle dans le cluster et de la charge du cluster.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/03 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/03 (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."]]
