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 du serveur d'API Kubernetes incluent les adresses IP et IP virtuelles des nœuds du plan de contrôle, ainsi que les noms DNS Kubernetes. Grâce à la fonctionnalité de réseaux SAN supplémentaires pour le certificat du serveur d'API personnalisé, vous pouvez ajouter des domaines, des sous-domaines et des adresses IP supplémentaires en tant que SAN au certificat du serveur d'API Kubernetes pour le cluster.
Pour spécifier des SAN personnalisés pour le certificat du serveur d'API, utilisez le champ controlPlane.apiServerCertExtraSANs dans les spécifications de configuration du cluster. Ce champ accepte 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 lors de la création d'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, cela déclenche les activités suivantes:
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 actualiser le nouveau certificat.
Les nouvelles valeurs de
apiServerCertExtraSANssont vérifiées par un webhook pour s'assurer qu'elles sont conformes aux conventions relatives aux noms de domaine RFC 1035.Le pool de nœuds du plan de contrôle passe à l'é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 la modification a été propagée 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 rencontrer un temps d'arrêt lors de la mise à jour du champ "SAN supplémentaires du certificat du serveur d'API" sur un cluster en cours d'exécution:
Sur les clusters à haute disponibilité, les instances de 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 d'API. Toutefois, vous pouvez recevoir une réponse indiquant que le serveur d'API est en cours d'arrêt. Si cette réponse s'affiche, relancez la requête.
Sur les clusters standards, une brève interruption d'environ une minute peut se produire pendant qu'un serveur d'API redémarre pour actualiser le nouveau certificat.
La propagation de la modification à tous les serveurs d'API prend 5 à 20 minutes, en fonction du nombre de nœuds de plan de contrôle dans le cluster et de la charge du cluster.