Ce document vous guide tout au long du processus de configuration de votre environnement Azure et d’installation de CloudPrem sur Azure AKS.
Prérequis
Avant d’installer CloudPrem sur Azure, vous devez mettre en place un ensemble de ressources d’infrastructure de support. Ces composants fournissent les services de calcul, de stockage, de base de données et de réseau sur lesquels CloudPrem s’appuie.
Prérequis d’infrastructure
Voici les composants que vous devez provisionner :
Azure Kubernetes Service (AKS) : un cluster AKS opérationnel dimensionné pour votre charge de travail CloudPrem attendue.
PostgreSQL Flexible Server : une instance Azure Database pour PostgreSQL que CloudPrem utilisera pour stocker ses métadonnées.
Contrôleur d’entrée NGINX : installé sur le cluster AKS pour router le trafic externe vers les services CloudPrem.
Agent Datadog : déployé sur le cluster AKS pour collecter et envoyer des logs à CloudPrem.
Azure Kubernetes Service (AKS)
CloudPrem s’exécute entièrement sur Kubernetes. Vous avez besoin d’un cluster AKS avec suffisamment de CPU, de mémoire et d’espace disque configurés pour votre charge de travail. Consultez les recommandations de dimensionnement du cluster Kubernetes pour obtenir des conseils.
Pour confirmer que le cluster est accessible et que les nœuds sont à l’état Ready, exécutez la commande suivante :
kubectl get nodes -o wide
Azure PostgreSQL Flexible Server
CloudPrem stocke ses métadonnées et sa configuration dans une base de données PostgreSQL. Datadog recommande Azure Database pour PostgreSQL Flexible Server. Elle doit être accessible depuis le cluster AKS, idéalement avec la mise en réseau privé activée. Consultez les recommandations de dimensionnement Postgres pour plus de détails.
Pour des raisons de sécurité, créez une base de données et un utilisateur dédiés pour CloudPrem, et accordez à cet utilisateur des droits uniquement sur cette base de données, et non à l'échelle du cluster.
Connectez-vous à votre base de données PostgreSQL depuis le réseau AKS à l’aide du client PostgreSQL psql. Démarrez d’abord un pod interactif dans votre cluster Kubernetes en utilisant une image incluant psql :
CloudPrem utilise Azure Blob Storage pour persister les logs. Créez un conteneur dédié à cet usage.
Créer un conteneur Blob Storage
Utilisez un conteneur dédié par environnement (par exemple, cloudprem-prod, cloudprem-staging), et attribuez des rôles RBAC avec le principe du moindre privilège au niveau du conteneur, plutôt qu’au niveau du compte de stockage.
Une application Azure AD doit disposer d’un accès en lecture/écriture au conteneur Blob Storage. Enregistrez une application dédiée pour CloudPrem et attribuez au principal de service correspondant le rôle Contributor sur le conteneur Blob Storage créé précédemment.
L’ingress public est indispensable pour permettre au plan de contrôle et au service de requêtes de Datadog de gérer et d’interroger les clusters CloudPrem via l’internet public. Il fournit un accès sécurisé à l’API gRPC de CloudPrem via les mécanismes suivants :
Crée un Azure Load Balancer accessible depuis internet qui accepte le trafic en provenance des services Datadog
Implémente le chiffrement TLS avec terminaison au niveau du contrôleur d’entrée
Utilise HTTP/2 (gRPC) pour la communication entre Datadog et les clusters CloudPrem
Requiert une authentification mTLS mutuelle où les services Datadog doivent présenter des certificats client valides
Configure le contrôleur en mode TLS passthrough pour transmettre les certificats client aux pods CloudPrem via l’en-tête ssl-client-cert
Rejette les requêtes ne présentant pas de certificats client valides ou l’en-tête de certificat
Utilisez le fichier de valeurs Helm nginx-public.yaml suivant pour créer le contrôleur d’entrée NGINX public :
Vérifiez que le pod du contrôleur est en cours d’exécution :
kubectl get pods -n nginx-ingress-public -l app.kubernetes.io/component=controller
Vérifiez que le service expose une IP externe :
kubectl get svc -n nginx-ingress-public -l app.kubernetes.io/component=controller
Contrôleur d’entrée NGINX interne
L’ingress interne permet l’ingestion de logs depuis les Agents Datadog et d’autres collecteurs de logs au sein de votre environnement via HTTP. Utilisez le fichier de valeurs Helm nginx-internal.yaml suivant pour créer le contrôleur d’entrée NGINX interne :
Vérifiez que le pod du contrôleur est en cours d'exécution :
```shell
kubectl get pods -n nginx-ingress-internal -l app.kubernetes.io/component=controller
Vérifiez que le service expose une IP externe :
kubectl get svc -n nginx-ingress-internal -l app.kubernetes.io/component=controller
DNS
Vous pouvez également ajouter une entrée DNS pointant vers l’IP du répartiteur de charge public, afin que les éventuels changements d’IP futurs ne nécessitent pas de mise à jour de la configuration côté Datadog.
Stockez la chaîne de connexion à la base de données PostgreSQL en tant que secret Kubernetes :
Pour récupérer les informations de connexion PostgreSQL, accédez au portail Azure, naviguez vers Toutes les ressources, puis cliquez sur votre instance Azure Database pour PostgreSQL Flexible Server. Ensuite, dans l’onglet Prise en main, cliquez sur le lien Afficher les chaînes de connexion dans la carte Connexion.
Créez un fichier datadog-values.yaml pour remplacer les valeurs par défaut par votre configuration personnalisée. C’est ici que vous définissez les paramètres spécifiques à l’environnement, tels que le tag d’image, l’ID de tenant Azure, le compte de service, la configuration de l’ingress, les demandes et limites de ressources, etc.
Tout paramètre non explicitement remplacé dans datadog-values.yaml utilise les valeurs par défaut définies dans le fichier values.yaml du chart.
# Show default values helm show values datadog/cloudprem
Voici un exemple de fichier datadog-values.yaml avec des valeurs personnalisées pour Azure :
datadog-values.yaml
# Datadog configurationdatadog:# The Datadog site (https://docs.datadoghq.com/getting_started/site/) to connect to. Defaults to `datadoghq.com`.# site: datadoghq.com# The name of the existing Secret containing the Datadog API key. The secret key name must be `api-key`.apiKeyExistingSecret:datadog-secretazure:tenantId:<TENANT_ID># requiredclientId:<CLIENT_ID># required when using AD App to authenticate with Blob StorageclientSecretRef:name:<SECRET_NAME>key:<SECRET_KEY>storageAccount:name:<STORAGE_ACCOUNT_NAME># required# If you are using a storage account access key to authenticate with Blob Storage,# comment out the `clientSecretRef` section above,# and uncomment the `storageAccount` section below:# accessKeySecretRef:# name: <SECRET_NAME># key: <SECRET_KEY># Service account configuration# If `serviceAccount.create` is set to `true`, a service account is created with the specified name.# Additional annotations can be added using serviceAccount.extraAnnotations.serviceAccount:create:truename:cloudprem# CloudPrem node configurationconfig:# The root URI where index data is stored. This should be an Azure path.# All indexes created in CloudPrem are stored under this location.default_index_root_uri:azure://<CONTAINER_NAME>/indexes# Internal ingress configuration# The internal ingress NLB is created in private subnets.## Additional annotations can be added to customize the ALB behavior.ingress:# The internal ingress is used by Datadog Agents and other collectors running outside# the Kubernetes cluster to send their logs to CloudPrem.internal:enabled:trueingressClassName:nginx-internalhost:cloudprem.acme.internalextraAnnotations:{}# Metastore configuration# The metastore is responsible for storing and managing index metadata.# It requires a PostgreSQL database connection string to be provided by a Kubernetes secret.# The secret should contain a key named `QW_METASTORE_URI` with a value in the format:# postgresql://<username>:<password>@<host>:<port>/<database>## The metastore connection string is mounted into the pods using extraEnvFrom to reference the secret.metastore:extraEnvFrom:- secretRef:name:cloudprem-metastore-uri# Indexer configuration# The indexer is responsible for processing and indexing incoming data it receives data from various sources (for example, Datadog Agents, log collectors)# and transforms it into searchable files called "splits" stored in S3.## The indexer is horizontally scalable - you can increase `replicaCount` to handle higher indexing throughput.# The `podSize` parameter sets vCPU, memory, and component-specific settings automatically.# See the sizing guide for available tiers and their configurations.indexer:replicaCount:2podSize:xlarge# Searcher configuration# The searcher is responsible for executing search queries against the indexed data stored in S3.# It handles search requests from Datadog's query service and returns matching results.## The searcher is horizontally scalable - you can increase `replicaCount` to handle more concurrent searches.# Resource requirements for searchers are highly workload-dependent and should be determined empirically.# Key factors that impact searcher performance include:# - Query complexity (for example, number of terms, use of wildcards or regex)# - Query concurrency (number of simultaneous searches)# - Amount of data scanned per query# - Data access patterns (cache hit rates)## Memory is particularly important for searchers as they cache frequently accessed index data in memory.searcher:replicaCount:2podSize:xlarge