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.
...
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:
...
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
apiServerCertExtraSANssont 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.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: ReconcilingLe 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.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
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.