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

Sélectionnez une version de la documentation :

Cette présentation décrit les configurations de connexion et d'accès essentielles 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 domaines 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 Kubernetes ClusterIP ou un accès externe à l'aide d'un LoadBalancer, y compris 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 et 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 CRD DBCluster.

Connectivité interne

Par défaut, les instances AlloyDB Omni sont exposées à l'aide d'un service Kubernetes ClusterIP. 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 (CR) PgBouncer pour simplifier cette opération.

Pour en savoir plus sur la configuration de PgBouncer, consultez la documentation de référence sur CRD PgBouncer Reference.

Déploiement et configuration

Créez une ressource PgBouncer et référencez votre cluster de base 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 cela 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 CRD UserDefinedAuthentication.

  • Par certificat (prévu) : la prise en charge de 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