Un SAN 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 IP virtuelles des nœuds du plan de contrôle, ainsi que les noms DNS Kubernetes. La fonctionnalité SAN supplémentaires pour les certificats de serveur d'API personnalisés vous permet d'ajouter des domaines, sous-domaines et 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 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, les activités suivantes sont déclenchées:
Les contrôleurs de cluster Google Distributed Cloud génèrent à nouveau le certificat de serveur d'API pour inclure les domaines supplémentaires modifiés.
Les contrôleurs du cluster redémarrent le serveur d'API pour actualiser le nouveau certificat.
Les nouvelles valeurs de
apiServerCertExtraSANssont validées par un webhook afin de s'assurer qu'elles sont conformes aux conventions de nom de domaine RFC 1035.Le pool de nœuds du plan de contrôle est en phase 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 pouvez rencontrer des 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, il peut y avoir une brève interruption d'environ une minute pendant qu'un serveur d'API redémarre pour recharger 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 de celui-ci.