Sécurité
Avant d'installer ou de mettre à niveau l'opérateur de surveillance NetApp Kubernetes
Suggérer des modifications
PDF
Lisez ces informations avant d'installer l'outil de mise à niveau de l'opérateur de surveillance Kubernetes NetApp
Conditions préalables :
-
Si vous utilisez un référentiel docker personnalisé ou privé, suivez les instructions de la section utilisation d'un référentiel docker personnalisé ou privé
-
L'installation de NetApp Kubernetes Monitoring Operator est prise en charge avec Kubernetes version 1.20 ou ultérieure.
-
Lorsque Cloud Insights contrôle le stockage back-end et que Kubernetes est utilisé avec le runtime du conteneur Docker, Cloud Insights peut afficher les mappages du pod au volume PV et les metrics pour NFS et iSCSI. Les autres runtimes affichent uniquement NFS.
-
Depuis août 2022, l'opérateur de surveillance NetApp Kubernetes inclut la prise en charge de Pod Security Policy (PSP). Si votre environnement utilise PSP, vous devez effectuer la mise à niveau vers l'opérateur de surveillance NetApp Kubernetes le plus récent.
-
Si vous utilisez OpenShift 4.6 ou une version supérieure, vous devez suivre les instructions OpenShift ci-dessous en plus de vous assurer que ces conditions préalables sont remplies.
-
La surveillance est uniquement installée sur les nœuds Linux. Cloud Insights prend en charge la surveillance des nœuds Kubernetes qui exécutent Linux, en spécifiant un sélecteur de nœuds Kubernetes qui recherche les étiquettes Kubernetes suivantes sur ces plateformes :
Plateforme |
Étiquette |
Kubernetes v1.20 et versions ultérieures |
Kubernetes.io/os = linux |
Rancher + bétail.io comme plateforme d'orchestration/Kubernetes |
bétail.io/os = linux |
-
L'opérateur de surveillance NetApp Kubernetes et ses dépendances (télégraf, indicateurs d'état kube, fluentbit, etc.) ne sont pas pris en charge sur les nœuds exécutant l'architecture ArMD64.
-
Les commandes suivantes doivent être disponibles : curl, kubectl. La commande docker est requise pour une étape d'installation facultative. Pour obtenir de meilleurs résultats, ajoutez ces commandes au CHEMIN D'ACCÈS. Notez que kubectl doit être configuré avec un accès minimal aux objets kubernetes suivants : agents, rôles de cluster, liaisons de clusters, définitions de ressources personnalisées, déploiements, espaces de noms, rôles, liaisons, secrets, comptes de service, et services netapp. Voir ici pour un exemple de fichier .yaml avec ces privilèges minimum de clusterrole.
-
L'hôte que vous utiliserez pour l'installation de l'opérateur de surveillance NetApp Kubernetes doit avoir kubectl configuré pour communiquer avec le cluster K8s cible et disposer d'une connectivité Internet à votre environnement Cloud Insights.
-
Si vous êtes derrière un proxy pendant l'installation ou lorsque vous utilisez le cluster K8s à surveiller, suivez les instructions de la section Configuration de la prise en charge du proxy.
-
L'opérateur de surveillance NetApp Kubernetes installe ses propres metrics kube-State pour éviter les conflits avec d'autres instances. Pour un audit et un reporting précis des données, il est vivement recommandé de synchroniser l'heure sur l'ordinateur de l'agent à l'aide du protocole NTP (Network Time Protocol) ou SNTP (simple Network Time Protocol).
-
Si vous redéployez l'opérateur (c'est-à-dire que vous le mettez à jour ou le remplacez), il n'est pas nécessaire de créer un jeton New API ; vous pouvez réutiliser le jeton précédent.
-
Notez également que si un opérateur de surveillance NetApp Kubernetes est récemment installé et qu'un jeton d'accès d'API renouvelable est utilisé, les tokens arrivant à expiration seront automatiquement remplacés par des jetons d'accès d'API nouveaux/mis à jour.
-
Surveillance du réseau :
-
Nécessite le noyau Linux version 4.18.0 et ultérieure
-
Le système d'exploitation de photons n'est pas pris en charge.
-
Configuration de l'opérateur
Dans les nouvelles versions de l'opérateur, les paramètres les plus fréquemment modifiés peuvent être configurés dans la ressource personnalisée AgentConfiguration. Vous pouvez modifier cette ressource avant de déployer l'opérateur en modifiant le fichier Operator-config.yaml. Ce fichier contient des exemples de paramètres commentés. Voir la liste des "paramètres disponibles" pour la version la plus récente de l'opérateur.
Vous pouvez également modifier cette ressource après le déploiement de l'opérateur à l'aide de la commande suivante :
kubectl -n netapp-monitoring edit AgentConfiguration Pour déterminer si votre version déployée de l'opérateur prend en charge AgentConfiguration, exécutez la commande suivante :
kubectl get crd agentconfigurations.monitoring.netapp.com Si vous voyez un message “erreur du serveur (NotFound)”, votre opérateur doit être mis à niveau avant de pouvoir utiliser AgentConfiguration.
Points importants à noter avant de commencer
Si vous utilisez un proxy, ont un référentiel personnalisé, ou utilisent OpenShift, lisez attentivement les sections suivantes.
Lisez également à propos de Autorisations.
Si vous effectuez une mise à niveau à partir d'une installation précédente, lisez le Mise à niveau informations.
Configuration du support de proxy
Pour installer l'opérateur NetApp Kubernetes Monitoring, vous pouvez utiliser un proxy dans votre environnement. Il peut s'agir de systèmes proxy identiques ou distincts :
-
Proxy requis lors de l'exécution de l'extrait de code d'installation (en utilisant "curl") pour connecter le système sur lequel l'extrait est exécuté dans votre environnement Cloud Insights
-
Proxy nécessaire du cluster Kubernetes cible pour communiquer avec votre environnement Cloud Insights
Si vous utilisez un proxy pour l'une ou l'autre de ces opérations, ou pour les deux, vous NetApp devez d'abord vous assurer que votre proxy est configuré pour permettre une bonne communication avec votre environnement Cloud Insights. Par exemple, à partir des serveurs/machines virtuelles à partir desquels vous souhaitez installer l'opérateur, vous devez pouvoir accéder à Cloud Insights et télécharger des binaires à partir de Cloud Insights.
Pour le proxy utilisé pour installer le moniteur d'exploitation NetApp Kubernetes, définissez les variables d'environnement http_proxy/https_proxy avant d'installer l'opérateur. Pour certains environnements proxy, il peut être nécessaire de définir la variable no_proxy Environment.
Pour définir la ou les variables, effectuez les opérations suivantes sur votre système avant d'installer NetApp Kubernetes Monitoring Operator :
-
Définissez les variables d'environnement https_proxy et/ou http_proxy pour l'utilisateur actuel :
-
Si le proxy en cours de configuration n'a pas d'authentification (nom d'utilisateur/mot de passe), exécutez la commande suivante :
export https_proxy=<proxy_server>:<proxy_port> .. Si le proxy en cours de configuration dispose d'une authentification (nom d'utilisateur/mot de passe), exécutez la commande suivante :
export http_proxy=<proxy_username>:<proxy_password>@<proxy_server>:<proxy_port>
-
Pour que le proxy utilisé pour votre cluster Kubernetes puisse communiquer avec votre environnement Cloud Insights, installez l'opérateur NetApp Kubernetes Monitoring après avoir lu toutes ces instructions.
Configurez la section proxy de AgentConfiguration dans Operator-config.yaml avant de déployer l'opérateur de surveillance NetApp Kubernetes.
agent:
...
proxy:
server: <server for proxy>
port: <port for proxy>
username: <username for proxy>
password: <password for proxy>
# In the noproxy section, enter a comma-separated list of
# IP addresses and/or resolvable hostnames that should bypass
# the proxy
noproxy: <comma separated list>
isTelegrafProxyEnabled: true
isFluentbitProxyEnabled: <true or false> # true if Events Log enabled
isCollectorsProxyEnabled: <true or false> # true if Network Performance and Map enabled
isAuProxyEnabled: <true or false> # true if AU enabled
...
...
À l'aide d'un référentiel docker personnalisé ou privé
Par défaut, l'opérateur de surveillance NetApp Kubernetes extrait les images du conteneur du référentiel Cloud Insights. Si vous utilisez un cluster Kubernetes comme cible de surveillance et que ce cluster est configuré pour extraire uniquement les images de conteneur à partir d'un référentiel Docker personnalisé ou privé ou d'un registre de conteneurs, vous devez configurer l'accès aux conteneurs requis par l'opérateur de surveillance NetApp Kubernetes.
Exécutez l'extrait de code image dans la mosaïque d'installation de NetApp Monitoring Operator. Cette commande permet de se connecter au référentiel Cloud Insights, d'extraire toutes les dépendances d'image pour l'opérateur et de se déconnecter du référentiel Cloud Insights. Lorsque vous y êtes invité, saisissez le mot de passe temporaire du référentiel fourni. Cette commande permet de télécharger toutes les images utilisées par l'opérateur, y compris pour les fonctions facultatives. Voir ci-dessous pour connaître les caractéristiques auxquelles ces images sont utilisées.
Fonctionnalités centrales de l'opérateur et surveillance Kubernetes
-
surveillance netapp
-
proxy kube-rbac
-
metrics-état-kube
-
telegraf
-
utilisateur-root-distroless
Journal des événements
-
fluent-bit
-
exportateur-événements-kubernetes
Performances et carte réseau
-
ci-net-observateur
Envoyez l'image de docker de l'opérateur à votre référentiel docker privé, local ou d'entreprise, conformément aux règles de votre entreprise. Assurez-vous que les balises d'image et les chemins de répertoire de ces images dans votre référentiel sont cohérents avec ceux du référentiel Cloud Insights.
Modifiez le déploiement de l'opérateur de surveillance dans Operator-deployment.yaml, et modifiez toutes les références d'image pour utiliser votre référentiel Docker privé.
image: <docker repo of the enterprise/corp docker repo>/kube-rbac-proxy:<kube-rbac-proxy version> image: <docker repo of the enterprise/corp docker repo>/netapp-monitoring:<version>
Modifiez la configuration d'agentConfiguration dans Operator-config.yaml pour refléter le nouvel emplacement docker repo. Créez une nouvelle imagePullSecret pour votre référentiel privé. Pour plus de détails, voir https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
agent: ... # An optional docker registry where you want docker images to be pulled from as compared to CI's docker registry # Please see documentation link here: https://docs.netapp.com/us-en/cloudinsights/task_config_telegraf_agent_k8s.html#using-a-custom-or-private-docker-repository dockerRepo: your.docker.repo/long/path/to/test # Optional: A docker image pull secret that maybe needed for your private docker registry dockerImagePullSecret: docker-secret-name
Instructions OpenShift
Si vous exécutez sur OpenShift 4.6 ou une version ultérieure, vous devez modifier la configuration d'agentConfiguration dans operator-config.yaml pour activer le paramètre runPrivileged :
# Set runPrivileged to true SELinux is enabled on your kubernetes nodes runPrivileged: true
OpenShift peut implémenter un niveau de sécurité supplémentaire qui peut bloquer l'accès à certains composants Kubernetes.
Autorisations
Si le cluster que vous contrôlez contient des ressources personnalisées qui n'ont pas de ClusterRole qui "agrégats à afficher", Vous devrez accorder manuellement à l'opérateur l'accès à ces ressources pour les surveiller avec les journaux d'événements.
-
Modifiez Operator-additional-permissions.yaml avant l'installation ou après l'installation, modifiez la ressource ClusterRole/<namespace>-additional-permissions
-
Créez une nouvelle règle pour les apiGroups et les ressources souhaités avec les verbes ["get", "Watch", "list"]. Voir https://kubernetes.io/docs/reference/access-authn-authz/rbac/
-
Appliquez vos modifications au cluster
Tolérances et tainations
Les netapp-ci-telegraf-ds, netapp-ci-Fluent-bit-ds et netapp-ci-net-observateur-l4-ds Demonsets doivent planifier un pod sur chaque nœud de votre cluster afin de collecter correctement les données sur tous les nœuds. L'opérateur a été configuré pour tolérer certains taints bien connus. Si vous avez configuré des fichiers d'accès personnalisés sur vos nœuds, empêchant ainsi les modules de s'exécuter sur chaque nœud, vous pouvez créer une tolérance pour ces fichiers d'accès "Dans AgentConfiguration". Si vous avez appliqué des rejets personnalisés à tous les nœuds de votre cluster, vous devez également ajouter les tolérances nécessaires au déploiement de l'opérateur pour permettre la planification et l'exécution du pod opérateur.
En savoir plus sur Kubernetes "Teintes et tolérances".