Présentation de la connexion de l'orchestrateur de conteneurs

Sélectionnez une version de la documentation :

Cette présentation décrit les configurations critiques de connexion et d'accès pour les bases de données AlloyDB Omni déployées sur un cluster Kubernetes. Elle explique également comment établir une connectivité flexible et sécurisée. La connexion comprend les éléments suivants :

  • Mise en réseau : découvrez comment configurer des clusters de bases de données AlloyDB Omni pour un accès interne à l'aide d'un service ClusterIP Kubernetes ou pour un accès externe à l'aide d'un LoadBalancer. Découvrez également comment limiter le trafic externe à l'aide de plages CIDR (Classless Inter-Domain Routing) sources.
  • Regroupement de connexions : utilisez la ressource personnalisée PgBouncer pour implémenter le regroupement de connexions afin de gérer efficacement les connexions et de réduire la charge sur les instances de base de données.
  • Authentification et autorisation : sécurisez l'accès à l'aide de méthodes compatibles telles que l'authentification par mot de passe, l'intégration d'Active Directory et de Kerberos, ainsi que le contrôle précis implémenté via les règles de réseau Kubernetes et les rôles PostgreSQL.

Mise en réseau

Vous pouvez configurer des clusters de bases de données AlloyDB Omni, gérés par la ressource personnalisée DBCluster, pour un accès interne ou externe.

Pour en savoir plus sur les options de mise en réseau DBCluster, consultez la documentation de référence sur la ressource personnalisée DBCluster Reference.

Connectivité interne

Par défaut, les instances AlloyDB Omni sont exposées à l'aide d'un service ClusterIP Kubernetes. Cela garantit que les instances ne sont accessibles qu'aux autres applications s'exécutant dans le même cluster Kubernetes. Vous trouverez le point de terminaison de l'instance principale dans l'état DBCluster.

Connectivité externe

Pour autoriser les connexions en dehors du cluster Kubernetes, mettez à jour la spécification DBCluster :

  • Activer le trafic externe : définissez spec.allowExternalIncomingTraffic: true, ce qui provisionne généralement un service LoadBalancer.
  • Implémenter un contrôle précis : utilisez spec.primarySpec.dbLoadBalancerOptions. Par exemple, sur Google Cloud, définissez gcp.loadBalancerType: "External" pour obtenir une adresse IP accessible depuis l'Internet public.

Limiter l'accès

Pour sécuriser les connexions externes, utilisez spec.primarySpec.sourceCidrRanges afin de définir une liste de plages CIDR autorisées. Le système bloque toutes les connexions provenant d'adresses IP en dehors de ces plages.

Regroupement de connexions avec PgBouncer

Pour gérer efficacement les connexions et réduire la charge des instances, utilisez PgBouncer. L'opérateur AlloyDB Omni fournit une ressource personnalisée PgBouncer pour simplifier cette opération.

Pour obtenir des informations complètes sur la configuration de PgBouncer, consultez la documentation de référence sur la ressource personnalisée PgBouncer CRD PgBouncer.

Déploiement et configuration

Créez une ressource PgBouncer et référencez votre cluster de bases de données dans spec.dbclusterRef. Les paramètres clés de spec.parameters incluent les éléments suivants :

  • pool_mode: détermine quand les connexions sont réutilisées (session, transaction ou statement).
  • default_pool_size : connexions serveur par utilisateur et par base de données.
  • max_client_conn : nombre maximal de connexions client autorisées.
  • max_db_connections: nombre maximal de connexions ouvertes à l'instance AlloyDB Omni.

Exposer PgBouncer

Utilisez spec.serviceOptions.type pour contrôler la visibilité.

  • ClusterIP : accès interne au cluster uniquement.
  • LoadBalancer : accès externe. Vous pouvez limiter cet accès avec spec.serviceOptions.loadBalancerSourceRanges à l'aide de blocs CIDR.

Authentification et autorisation

AlloyDB Omni est compatible avec plusieurs méthodes pour vérifier les identités et contrôler l'accès.

Méthodes d'authentification

  • Par mot de passe : authentification standard par nom d'utilisateur et mot de passe PostgreSQL. Le mot de passe administrateur est généralement fourni à l'aide d'un secret Kubernetes, comme illustré dans l'exemple complet de DBCluster Sample.

  • Active Directory et Kerberos : gérés à l'aide de la ressource personnalisée UserDefinedAuthentication. Cela est compatible avec GSSAPI et la synchronisation des groupes LDAP à l'aide des éléments suivants :

    • spec.keytabSecretRef : pour les keytabs Kerberos.
    • spec.ldapConfiguration : pour le mappage des groupes et les paramètres LDAP.
    • spec.pgHbaEntries: pour configurer les règles pg_hba.conf (par exemple, gss ou ldap).

    Pour en savoir plus, consultez la documentation de référence sur la ressource personnalisée UserDefinedAuthentication.

  • Par certificat (prévu) : la compatibilité avec l'authentification par certificat TLS sans mot de passe est prévue pour une prochaine version.

Autorisation et contrôle des accès

  • Règles de réseau Kubernetes : définissez des règles au niveau du pod pour sécuriser le trafic entre les applications et les pods AlloyDB Omni ou PgBouncer.
  • Plages CIDR sources : limitez le trafic au niveau du LoadBalancer.
  • Rôles PostgreSQL : utilisez les rôles et les privilèges de base de données standards pour gérer les autorisations des utilisateurs une fois qu'ils sont authentifiés.

Étape suivante