Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

5.5. Opérateur de conformité scans

Les API ScanSetting et ScanSettingBinding sont recommandées pour exécuter des analyses de conformité avec l'opérateur de conformité. Pour plus d'informations sur ces objets API, exécutez : 

$ oc explain scansettings
Copy to Clipboard Toggle word wrap

ou 

$ oc explain scansettingbindings
Copy to Clipboard Toggle word wrap

5.5.1. Exécution d'analyses de conformité
Copier lien

Vous pouvez lancer une analyse à l'aide des profils du Center for Internet Security (CIS). Pour des raisons pratiques, l'Opérateur de Conformité crée un objet ScanSetting avec des valeurs par défaut raisonnables au démarrage. Cet objet ScanSetting est nommé default.

Note

Pour les nœuds de plan de contrôle et de travailleur tout-en-un, l'analyse de conformité s'exécute deux fois sur les nœuds de plan de contrôle et de travailleur. L'analyse de conformité peut générer des résultats incohérents. Vous pouvez éviter les résultats incohérents en ne définissant qu'un seul rôle dans l'objet ScanSetting.

Procédure

  1. Inspecter l'objet ScanSetting en courant : 

    $ oc describe scansettings default -n openshift-compliance
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    Name:         default
Namespace:    openshift-compliance
Labels:       <none>
Annotations:  <none>
API Version:  compliance.openshift.io/v1alpha1
Kind:         ScanSetting
Metadata:
  Creation Timestamp:  2022-10-10T14:07:29Z
  Generation:          1
  Managed Fields:
    API Version:  compliance.openshift.io/v1alpha1
    Fields Type:  FieldsV1
    fieldsV1:
      f:rawResultStorage:
        .:
        f:nodeSelector:
          .:
          f:node-role.kubernetes.io/master:
        f:pvAccessModes:
        f:rotation:
        f:size:
        f:tolerations:
      f:roles:
      f:scanTolerations:
      f:schedule:
      f:showNotApplicable:
      f:strictNodeScan:
    Manager:         compliance-operator
    Operation:       Update
    Time:            2022-10-10T14:07:29Z
  Resource Version:  56111
  UID:               c21d1d14-3472-47d7-a450-b924287aec90
Raw Result Storage:
  Node Selector:
    node-role.kubernetes.io/master:
  Pv Access Modes:
    ReadWriteOnce
    1 
    
  Rotation:  3
    2 
    
  Size:      1Gi
    3 
    
  Tolerations:
    Effect:              NoSchedule
    Key:                 node-role.kubernetes.io/master
    Operator:            Exists
    Effect:              NoExecute
    Key:                 node.kubernetes.io/not-ready
    Operator:            Exists
    Toleration Seconds:  300
    Effect:              NoExecute
    Key:                 node.kubernetes.io/unreachable
    Operator:            Exists
    Toleration Seconds:  300
    Effect:              NoSchedule
    Key:                 node.kubernetes.io/memory-pressure
    Operator:            Exists
Roles:
  master
    4 
    
  worker
    5 
    
Scan Tolerations:
    6 
    
  Operator:           Exists
Schedule:             0 1 * * *
    7 
    
Show Not Applicable:  false
Strict Node Scan:     true
Events:               <none>
    Copy to Clipboard Toggle word wrap

    1
    L'opérateur de conformité crée un volume persistant (PV) qui contient les résultats des analyses. Par défaut, le PV utilisera le mode d'accès ReadWriteOnce car l'opérateur de conformité ne peut pas faire d'hypothèses sur les classes de stockage configurées sur le cluster. De plus, le mode d'accès ReadWriteOnce est disponible sur la plupart des clusters. Si vous avez besoin de récupérer les résultats de l'analyse, vous pouvez le faire en utilisant un pod d'aide, qui lie également le volume. Les volumes qui utilisent le mode d'accès ReadWriteOnce ne peuvent être montés que par un seul pod à la fois, il est donc important de ne pas oublier de supprimer les pods d'assistance. Sinon, l'opérateur de conformité ne pourra pas réutiliser le volume pour les analyses suivantes.
    2
    L'opérateur de conformité conserve les résultats de trois balayages ultérieurs dans le volume ; les balayages plus anciens font l'objet d'une rotation.
    3
    L'opérateur de conformité alloue un Go d'espace de stockage pour les résultats de l'analyse.
    4 5
    Si le paramètre d'analyse utilise des profils qui analysent les nœuds de cluster, analysez ces rôles de nœuds.
    6
    L'objet du paramètre d'analyse par défaut analyse tous les nœuds.
    7
    L'objet du paramètre de balayage par défaut exécute des balayages à 01:00 chaque jour.

    Pour remplacer le paramètre de numérisation par défaut, vous pouvez utiliser default-auto-apply, dont les paramètres sont les suivants : 

    Name:                      default-auto-apply
Namespace:                 openshift-compliance
Labels:                    <none>
Annotations:               <none>
API Version:               compliance.openshift.io/v1alpha1
Auto Apply Remediations:   true
Auto Update Remediations:  true
Kind:                      ScanSetting
Metadata:
  Creation Timestamp:  2022-10-18T20:21:00Z
  Generation:          1
  Managed Fields:
    API Version:  compliance.openshift.io/v1alpha1
    Fields Type:  FieldsV1
    fieldsV1:
      f:autoApplyRemediations:
    1 
    
      f:autoUpdateRemediations:
    2 
    
      f:rawResultStorage:
        .:
        f:nodeSelector:
          .:
          f:node-role.kubernetes.io/master:
        f:pvAccessModes:
        f:rotation:
        f:size:
        f:tolerations:
      f:roles:
      f:scanTolerations:
      f:schedule:
      f:showNotApplicable:
      f:strictNodeScan:
    Manager:         compliance-operator
    Operation:       Update
    Time:            2022-10-18T20:21:00Z
  Resource Version:  38840
  UID:               8cb0967d-05e0-4d7a-ac1c-08a7f7e89e84
Raw Result Storage:
  Node Selector:
    node-role.kubernetes.io/master:
  Pv Access Modes:
    ReadWriteOnce
  Rotation:  3
  Size:      1Gi
  Tolerations:
    Effect:              NoSchedule
    Key:                 node-role.kubernetes.io/master
    Operator:            Exists
    Effect:              NoExecute
    Key:                 node.kubernetes.io/not-ready
    Operator:            Exists
    Toleration Seconds:  300
    Effect:              NoExecute
    Key:                 node.kubernetes.io/unreachable
    Operator:            Exists
    Toleration Seconds:  300
    Effect:              NoSchedule
    Key:                 node.kubernetes.io/memory-pressure
    Operator:            Exists
Roles:
  master
  worker
Scan Tolerations:
  Operator:           Exists
Schedule:             0 1 * * *
Show Not Applicable:  false
Strict Node Scan:     true
Events:               <none>
    Copy to Clipboard Toggle word wrap
    1 2
    Le fait de définir les drapeaux autoUpdateRemediations et autoApplyRemediations sur true vous permet de créer facilement des objets ScanSetting qui s'auto-remédient sans étapes supplémentaires.

  2. Créez un objet ScanSettingBinding qui se lie à l'objet par défaut ScanSetting et analyse le cluster à l'aide des profils cis et cis-node. Par exemple : 

    apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSettingBinding
metadata:
  name: cis-compliance
  namespace: openshift-compliance
profiles:
  - name: ocp4-cis-node
    kind: Profile
    apiGroup: compliance.openshift.io/v1alpha1
  - name: ocp4-cis
    kind: Profile
    apiGroup: compliance.openshift.io/v1alpha1
settingsRef:
  name: default
  kind: ScanSetting
  apiGroup: compliance.openshift.io/v1alpha1
    Copy to Clipboard Toggle word wrap

  3. Créez l'objet ScanSettingBinding en exécutant la commande 

    $ oc create -f <file-name>.yaml -n openshift-compliance
    Copy to Clipboard Toggle word wrap

    A ce stade du processus, l'objet ScanSettingBinding est rapproché et basé sur les paramètres Binding et Bound. L'opérateur de conformité crée un objet ComplianceSuite et les objets ComplianceScan associés.

  4. Suivez la progression de l'analyse de conformité en exécutant le programme : 

    $ oc get compliancescan -w -n openshift-compliance
    Copy to Clipboard Toggle word wrap

    Les analyses passent par les phases d'analyse et atteignent finalement la phase DONE lorsqu'elles sont terminées. Dans la plupart des cas, le résultat de l'analyse est NON-COMPLIANT. Vous pouvez examiner les résultats de l'analyse et commencer à appliquer des mesures correctives pour rendre le cluster conforme. Pour plus d'informations, reportez-vous à la section Gestion de la remédiation de l'opérateur de conformité.

Le pod du serveur de résultats monte le volume persistant (PV) qui stocke les résultats bruts de l'analyse au format ARF (Asset Reporting Format). Les attributs nodeSelector et tolerations vous permettent de configurer l'emplacement du module de serveur de résultats.

Cette fonction est utile dans les environnements où les nœuds du plan de contrôle ne sont pas autorisés à monter des volumes persistants.

Procédure

  • Créer une ressource personnalisée (CR) ScanSetting pour l'opérateur de conformité :

    1. Définissez le CR ScanSetting et enregistrez le fichier YAML, par exemple rs-workers.yaml: 

      apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSetting
metadata:
  name: rs-on-workers
  namespace: openshift-compliance
rawResultStorage:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
      1 
      
  pvAccessModes:
  - ReadWriteOnce
  rotation: 3
  size: 1Gi
  tolerations:
  - operator: Exists
      2 
      
roles:
- worker
- master
scanTolerations:
  - operator: Exists
schedule: 0 1 * * *
      Copy to Clipboard Toggle word wrap
      1
      L'opérateur de conformité utilise ce nœud pour stocker les résultats de l'analyse au format ARF.
      2
      Le pod serveur de résultat tolère toutes les taches.

    2. Pour créer le CR ScanSetting, exécutez la commande suivante : 

      $ oc create -f rs-workers.yaml
      Copy to Clipboard Toggle word wrap

Vérification

  • Pour vérifier que l'objet ScanSetting est créé, exécutez la commande suivante : 

    $ oc get scansettings rs-on-workers -n openshift-compliance -o yaml
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSetting
metadata:
  creationTimestamp: "2021-11-19T19:36:36Z"
  generation: 1
  name: rs-on-workers
  namespace: openshift-compliance
  resourceVersion: "48305"
  uid: 43fdfc5f-15a7-445a-8bbc-0e4a160cd46e
rawResultStorage:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
  pvAccessModes:
  - ReadWriteOnce
  rotation: 3
  size: 1Gi
  tolerations:
  - operator: Exists
roles:
- worker
- master
scanTolerations:
- operator: Exists
schedule: 0 1 * * *
strictNodeScan: true
    Copy to Clipboard Toggle word wrap

5.5.3. ScanSetting Ressource personnalisée
Copier lien

La ressource personnalisée ScanSetting vous permet désormais d'outrepasser les limites de mémoire et de CPU par défaut des modules de numérisation grâce à l'attribut scan limits. L'Opérateur de Conformité utilisera les valeurs par défaut de 500Mi de mémoire, 100m CPU pour le conteneur scanner, et 200Mi de mémoire avec 100m CPU pour le conteneur api-resource-collector. Pour définir les limites de mémoire de l'opérateur, modifiez l'objet Subscription s'il est installé via OLM ou le déploiement de l'opérateur lui-même.

Pour augmenter les limites par défaut du CPU et de la mémoire de l'Opérateur de Conformité, voir Increasing Compliance Operator resource limits.

Important

Il est nécessaire d'augmenter la limite de mémoire de l'opérateur de conformité ou des modules de numérisation si les limites par défaut ne sont pas suffisantes et que l'opérateur ou les modules de numérisation se terminent par le processus Out Of Memory (OOM).

5.5.4. Application des demandes et des limites de ressources
Copier lien

Lorsque le kubelet démarre un conteneur dans le cadre d'un pod, il transmet les demandes et les limites de ce conteneur en matière de mémoire et d'unité centrale à l'exécution du conteneur. Sous Linux, l'exécution du conteneur configure les cgroups du noyau qui appliquent et font respecter les limites que vous avez définies.

La limite de CPU définit le temps de CPU que le conteneur peut utiliser. Au cours de chaque intervalle de planification, le noyau Linux vérifie si cette limite est dépassée. Si c'est le cas, le noyau attend avant d'autoriser le cgroup à reprendre son exécution.

Si plusieurs conteneurs différents (cgroups) veulent s'exécuter sur un système contended, les charges de travail ayant des demandes d'UC plus importantes se voient attribuer plus de temps d'UC que les charges de travail ayant des demandes moins importantes. La demande de mémoire est utilisée lors de la planification des pods. Sur un nœud qui utilise cgroups v2, le moteur d'exécution du conteneur peut utiliser la demande de mémoire comme indice pour définir les valeurs memory.min et memory.low.

Si un conteneur tente d'allouer plus de mémoire que cette limite, le sous-système de sortie de mémoire du noyau Linux s'active et intervient en arrêtant l'un des processus du conteneur qui a tenté d'allouer de la mémoire. La limite de mémoire pour le Pod ou le conteneur peut également s'appliquer à des pages dans des volumes adossés à la mémoire, tels qu'un emptyDir.

Le kubelet suit les volumes tmpfs emptyDir au fur et à mesure que la mémoire du conteneur est utilisée, plutôt que comme un stockage éphémère local. Si un conteneur dépasse sa demande de mémoire et que le nœud sur lequel il s'exécute manque de mémoire, le conteneur du pod peut être expulsé.

Important

Un conteneur ne peut pas dépasser sa limite de CPU pendant de longues périodes. Les temps d'exécution des conteneurs n'arrêtent pas les pods ou les conteneurs en cas d'utilisation excessive du processeur. Pour déterminer si un conteneur ne peut pas être planifié ou s'il est tué en raison de limites de ressources, voir Troubleshooting the Compliance Operator.

Lorsqu'un module est créé, le planificateur sélectionne un nœud sur lequel le module doit s'exécuter. Chaque nœud a une capacité maximale pour chaque type de ressource en ce qui concerne la quantité de CPU et de mémoire qu'il peut fournir aux Pods. L'ordonnanceur veille à ce que la somme des demandes de ressources des conteneurs programmés soit inférieure à la capacité des nœuds pour chaque type de ressource.

Même si l'utilisation de la mémoire ou de l'unité centrale sur les nœuds est très faible, le planificateur peut toujours refuser de placer un pod sur un nœud si la vérification de la capacité ne permet pas de se prémunir contre une pénurie de ressources sur un nœud.

Pour chaque conteneur, vous pouvez spécifier les limites de ressources et les demandes suivantes : 

spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
spec.containers[].resources.limits.hugepages-<size>
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory
spec.containers[].resources.requests.hugepages-<size>
Copy to Clipboard Toggle word wrap

Bien que vous puissiez spécifier des demandes et des limites pour des conteneurs individuels, il est également utile de prendre en compte les demandes et les limites de ressources globales pour un module. Pour une ressource particulière, une demande ou une limite de ressource de conteneur est la somme des demandes ou des limites de ressources de ce type pour chaque conteneur dans le module.

Exemple de demandes et de limites de ressources pour les conteneurs

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
1 

        memory: "64Mi"
        cpu: "250m"
      limits:
2 

        memory: "128Mi"
        cpu: "500m"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
Copy to Clipboard Toggle word wrap

1
Le conteneur demande 64 Mio de mémoire et 250 Mio de CPU.
2
Les limites du conteneur sont 128 Mi de mémoire et 500 m de CPU.
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat