Procédure

1. Se connecter à un cluster.

2. Exécutez la commande suivante, qui interroge le service Prometheus d'un cluster et renvoie l'ensemble des données de séries temporelles capturées par Telemetry :

   $ curl -G -k -H "Authorization: Bearer $(oc whoami -t)" \
   https://$(oc get route prometheus-k8s-federate -n \
   openshift-monitoring -o jsonpath="{.spec.host}")/federate \
   --data-urlencode 'match[]={__name__=~"cluster:usage:.*"}' \
   --data-urlencode 'match[]={__name__="count:up0"}' \
   --data-urlencode 'match[]={__name__="count:up1"}' \
   --data-urlencode 'match[]={__name__="cluster_version"}' \
   --data-urlencode 'match[]={__name__="cluster_version_available_updates"}' \
   --data-urlencode 'match[]={__name__="cluster_version_capability"}' \
   --data-urlencode 'match[]={__name__="cluster_operator_up"}' \
   --data-urlencode 'match[]={__name__="cluster_operator_conditions"}' \
   --data-urlencode 'match[]={__name__="cluster_version_payload"}' \
   --data-urlencode 'match[]={__name__="cluster_installer"}' \
   --data-urlencode 'match[]={__name__="cluster_infrastructure_provider"}' \
   --data-urlencode 'match[]={__name__="cluster_feature_set"}' \
   --data-urlencode 'match[]={__name__="instance:etcd_object_counts:sum"}' \
   --data-urlencode 'match[]={__name__="ALERTS",alertstate="firing"}' \
   --data-urlencode 'match[]={__name__="code:apiserver_request_total:rate:sum"}' \
   --data-urlencode 'match[]={__name__="cluster:capacity_cpu_cores:sum"}' \
   --data-urlencode 'match[]={__name__="cluster:capacity_memory_bytes:sum"}' \
   --data-urlencode 'match[]={__name__="cluster:cpu_usage_cores:sum"}' \
   --data-urlencode 'match[]={__name__="cluster:memory_usage_bytes:sum"}' \
   --data-urlencode 'match[]={__name__="openshift:cpu_usage_cores:sum"}' \
   --data-urlencode 'match[]={__name__="openshift:memory_usage_bytes:sum"}' \
   --data-urlencode 'match[]={__name__="workload:cpu_usage_cores:sum"}' \
   --data-urlencode 'match[]={__name__="workload:memory_usage_bytes:sum"}' \
   --data-urlencode 'match[]={__name__="cluster:virt_platform_nodes:sum"}' \
   --data-urlencode 'match[]={__name__="cluster:node_instance_type_count:sum"}' \
   --data-urlencode 'match[]={__name__="cnv:vmi_status_running:count"}' \
   --data-urlencode 'match[]={__name__="cluster:vmi_request_cpu_cores:sum"}' \
   --data-urlencode 'match[]={__name__="node_role_os_version_machine:cpu_capacity_cores:sum"}' \
   --data-urlencode 'match[]={__name__="node_role_os_version_machine:cpu_capacity_sockets:sum"}' \
   --data-urlencode 'match[]={__name__="subscription_sync_total"}' \
   --data-urlencode 'match[]={__name__="olm_resolution_duration_seconds"}' \
   --data-urlencode 'match[]={__name__="csv_succeeded"}' \
   --data-urlencode 'match[]={__name__="csv_abnormal"}' \
   --data-urlencode 'match[]={__name__="cluster:kube_persistentvolumeclaim_resource_requests_storage_bytes:provisioner:sum"}' \
   --data-urlencode 'match[]={__name__="cluster:kubelet_volume_stats_used_bytes:provisioner:sum"}' \
   --data-urlencode 'match[]={__name__="ceph_cluster_total_bytes"}' \
   --data-urlencode 'match[]={__name__="ceph_cluster_total_used_raw_bytes"}' \
   --data-urlencode 'match[]={__name__="ceph_health_status"}' \
   --data-urlencode 'match[]={__name__="odf_system_raw_capacity_total_bytes"}' \
   --data-urlencode 'match[]={__name__="odf_system_raw_capacity_used_bytes"}' \
   --data-urlencode 'match[]={__name__="odf_system_health_status"}' \
   --data-urlencode 'match[]={__name__="job:ceph_osd_metadata:count"}' \
   --data-urlencode 'match[]={__name__="job:kube_pv:count"}' \
   --data-urlencode 'match[]={__name__="job:odf_system_pvs:count"}' \
   --data-urlencode 'match[]={__name__="job:ceph_pools_iops:total"}' \
   --data-urlencode 'match[]={__name__="job:ceph_pools_iops_bytes:total"}' \
   --data-urlencode 'match[]={__name__="job:ceph_versions_running:count"}' \
   --data-urlencode 'match[]={__name__="job:noobaa_total_unhealthy_buckets:sum"}' \
   --data-urlencode 'match[]={__name__="job:noobaa_bucket_count:sum"}' \
   --data-urlencode 'match[]={__name__="job:noobaa_total_object_count:sum"}' \
   --data-urlencode 'match[]={__name__="odf_system_bucket_count", system_type="OCS", system_vendor="Red Hat"}' \
   --data-urlencode 'match[]={__name__="odf_system_objects_total", system_type="OCS", system_vendor="Red Hat"}' \
   --data-urlencode 'match[]={__name__="noobaa_accounts_num"}' \
   --data-urlencode 'match[]={__name__="noobaa_total_usage"}' \
   --data-urlencode 'match[]={__name__="console_url"}' \
   --data-urlencode 'match[]={__name__="cluster:ovnkube_master_egress_routing_via_host:max"}' \
   --data-urlencode 'match[]={__name__="cluster:network_attachment_definition_instances:max"}' \
   --data-urlencode 'match[]={__name__="cluster:network_attachment_definition_enabled_instance_up:max"}' \
   --data-urlencode 'match[]={__name__="cluster:ingress_controller_aws_nlb_active:sum"}' \
   --data-urlencode 'match[]={__name__="cluster:route_metrics_controller_routes_per_shard:min"}' \
   --data-urlencode 'match[]={__name__="cluster:route_metrics_controller_routes_per_shard:max"}' \
   --data-urlencode 'match[]={__name__="cluster:route_metrics_controller_routes_per_shard:avg"}' \
   --data-urlencode 'match[]={__name__="cluster:route_metrics_controller_routes_per_shard:median"}' \
   --data-urlencode 'match[]={__name__="cluster:openshift_route_info:tls_termination:sum"}' \
   --data-urlencode 'match[]={__name__="insightsclient_request_send_total"}' \
   --data-urlencode 'match[]={__name__="cam_app_workload_migrations"}' \
   --data-urlencode 'match[]={__name__="cluster:apiserver_current_inflight_requests:sum:max_over_time:2m"}' \
   --data-urlencode 'match[]={__name__="cluster:alertmanager_integrations:max"}' \
   --data-urlencode 'match[]={__name__="cluster:telemetry_selected_series:count"}' \
   --data-urlencode 'match[]={__name__="openshift:prometheus_tsdb_head_series:sum"}' \
   --data-urlencode 'match[]={__name__="openshift:prometheus_tsdb_head_samples_appended_total:sum"}' \
   --data-urlencode 'match[]={__name__="monitoring:container_memory_working_set_bytes:sum"}' \
   --data-urlencode 'match[]={__name__="namespace_job:scrape_series_added:topk3_sum1h"}' \
   --data-urlencode 'match[]={__name__="namespace_job:scrape_samples_post_metric_relabeling:topk3"}' \
   --data-urlencode 'match[]={__name__="monitoring:haproxy_server_http_responses_total:sum"}' \
   --data-urlencode 'match[]={__name__="rhmi_status"}' \
   --data-urlencode 'match[]={__name__="status:upgrading:version:rhoam_state:max"}' \
   --data-urlencode 'match[]={__name__="state:rhoam_critical_alerts:max"}' \
   --data-urlencode 'match[]={__name__="state:rhoam_warning_alerts:max"}' \
   --data-urlencode 'match[]={__name__="rhoam_7d_slo_percentile:max"}' \
   --data-urlencode 'match[]={__name__="rhoam_7d_slo_remaining_error_budget:max"}' \
   --data-urlencode 'match[]={__name__="cluster_legacy_scheduler_policy"}' \
   --data-urlencode 'match[]={__name__="cluster_master_schedulable"}' \
   --data-urlencode 'match[]={__name__="che_workspace_status"}' \
   --data-urlencode 'match[]={__name__="che_workspace_started_total"}' \
   --data-urlencode 'match[]={__name__="che_workspace_failure_total"}' \
   --data-urlencode 'match[]={__name__="che_workspace_start_time_seconds_sum"}' \
   --data-urlencode 'match[]={__name__="che_workspace_start_time_seconds_count"}' \
   --data-urlencode 'match[]={__name__="cco_credentials_mode"}' \
   --data-urlencode 'match[]={__name__="cluster:kube_persistentvolume_plugin_type_counts:sum"}' \
   --data-urlencode 'match[]={__name__="visual_web_terminal_sessions_total"}' \
   --data-urlencode 'match[]={__name__="acm_managed_cluster_info"}' \
   --data-urlencode 'match[]={__name__="cluster:vsphere_vcenter_info:sum"}' \
   --data-urlencode 'match[]={__name__="cluster:vsphere_esxi_version_total:sum"}' \
   --data-urlencode 'match[]={__name__="cluster:vsphere_node_hw_version_total:sum"}' \
   --data-urlencode 'match[]={__name__="openshift:build_by_strategy:sum"}' \
   --data-urlencode 'match[]={__name__="rhods_aggregate_availability"}' \
   --data-urlencode 'match[]={__name__="rhods_total_users"}' \
   --data-urlencode 'match[]={__name__="instance:etcd_disk_wal_fsync_duration_seconds:histogram_quantile",quantile="0.99"}' \
   --data-urlencode 'match[]={__name__="instance:etcd_mvcc_db_total_size_in_bytes:sum"}' \
   --data-urlencode 'match[]={__name__="instance:etcd_network_peer_round_trip_time_seconds:histogram_quantile",quantile="0.99"}' \
   --data-urlencode 'match[]={__name__="instance:etcd_mvcc_db_total_size_in_use_in_bytes:sum"}' \
   --data-urlencode 'match[]={__name__="instance:etcd_disk_backend_commit_duration_seconds:histogram_quantile",quantile="0.99"}' \
   --data-urlencode 'match[]={__name__="jaeger_operator_instances_storage_types"}' \
   --data-urlencode 'match[]={__name__="jaeger_operator_instances_strategies"}' \
   --data-urlencode 'match[]={__name__="jaeger_operator_instances_agent_strategies"}' \
   --data-urlencode 'match[]={__name__="appsvcs:cores_by_product:sum"}' \
   --data-urlencode 'match[]={__name__="nto_custom_profiles:count"}' \
   --data-urlencode 'match[]={__name__="openshift_csi_share_configmap"}' \
   --data-urlencode 'match[]={__name__="openshift_csi_share_secret"}' \
   --data-urlencode 'match[]={__name__="openshift_csi_share_mount_failures_total"}' \
   --data-urlencode 'match[]={__name__="openshift_csi_share_mount_requests_total"}' \
   --data-urlencode 'match[]={__name__="cluster:velero_backup_total:max"}' \
   --data-urlencode 'match[]={__name__="cluster:velero_restore_total:max"}' \
   --data-urlencode 'match[]={__name__="eo_es_storage_info"}' \
   --data-urlencode 'match[]={__name__="eo_es_redundancy_policy_info"}' \
   --data-urlencode 'match[]={__name__="eo_es_defined_delete_namespaces_total"}' \
   --data-urlencode 'match[]={__name__="eo_es_misconfigured_memory_resources_info"}' \
   --data-urlencode 'match[]={__name__="cluster:eo_es_data_nodes_total:max"}' \
   --data-urlencode 'match[]={__name__="cluster:eo_es_documents_created_total:sum"}' \
   --data-urlencode 'match[]={__name__="cluster:eo_es_documents_deleted_total:sum"}' \
   --data-urlencode 'match[]={__name__="pod:eo_es_shards_total:max"}' \
   --data-urlencode 'match[]={__name__="eo_es_cluster_management_state_info"}' \
   --data-urlencode 'match[]={__name__="imageregistry:imagestreamtags_count:sum"}' \
   --data-urlencode 'match[]={__name__="imageregistry:operations_count:sum"}' \
   --data-urlencode 'match[]={__name__="log_logging_info"}' \
   --data-urlencode 'match[]={__name__="log_collector_error_count_total"}' \
   --data-urlencode 'match[]={__name__="log_forwarder_pipeline_info"}' \
   --data-urlencode 'match[]={__name__="log_forwarder_input_info"}' \
   --data-urlencode 'match[]={__name__="log_forwarder_output_info"}' \
   --data-urlencode 'match[]={__name__="cluster:log_collected_bytes_total:sum"}' \
   --data-urlencode 'match[]={__name__="cluster:log_logged_bytes_total:sum"}' \
   --data-urlencode 'match[]={__name__="cluster:kata_monitor_running_shim_count:sum"}' \
   --data-urlencode 'match[]={__name__="platform:hypershift_hostedclusters:max"}' \
   --data-urlencode 'match[]={__name__="platform:hypershift_nodepools:max"}' \
   --data-urlencode 'match[]={__name__="namespace:noobaa_unhealthy_bucket_claims:max"}' \
   --data-urlencode 'match[]={__name__="namespace:noobaa_buckets_claims:max"}' \
   --data-urlencode 'match[]={__name__="namespace:noobaa_unhealthy_namespace_resources:max"}' \
   --data-urlencode 'match[]={__name__="namespace:noobaa_namespace_resources:max"}' \
   --data-urlencode 'match[]={__name__="namespace:noobaa_unhealthy_namespace_buckets:max"}' \
   --data-urlencode 'match[]={__name__="namespace:noobaa_namespace_buckets:max"}' \
   --data-urlencode 'match[]={__name__="namespace:noobaa_accounts:max"}' \
   --data-urlencode 'match[]={__name__="namespace:noobaa_usage:max"}' \
   --data-urlencode 'match[]={__name__="namespace:noobaa_system_health_status:max"}' \
   --data-urlencode 'match[]={__name__="ocs_advanced_feature_usage"}' \
   --data-urlencode 'match[]={__name__="os_image_url_override:sum"}'

Procédure

1. Rechercher le nom du module en cours d'exécution pour l'opérateur Insights :

   $ INSIGHTS_OPERATOR_POD=$(oc get pods --namespace=openshift-insights -o custom-columns=:metadata.name --no-headers  --field-selector=status.phase=Running)

2. Copier les archives de données récentes collectées par l'opérateur Insights :

   $ oc cp openshift-insights/$INSIGHTS_OPERATOR_POD:/var/lib/insights-operator ./insights-data

Procédure

1. Téléchargez le secret d'extraction du cluster global sur votre système de fichiers local.

   $ oc extract secret/pull-secret -n openshift-config --to=.

2. Dans un éditeur de texte, modifiez le fichier .dockerconfigjson qui a été téléchargé.

3. Supprimer l'entrée JSON cloud.openshift.com, par exemple :

   \N- "cloud.openshift.com":{"auth":\N"<hash>\N",\N "email":\N"<email_address>\N"}

4. Enregistrer le fichier.

Procédure

1. Facultatif : Pour ajouter un nouveau secret d'extraction au secret d'extraction existant, procédez comme suit :

   1. Entrez la commande suivante pour télécharger le secret d'extraction :

      $ oc get secret/pull-secret -n openshift-config --template='{{index .data ".dockerconfigjson" | base64decode}}' ><pull_secret_location> 1

      1

      Indiquer le chemin d'accès au fichier de secret d'extraction.

   2. Entrez la commande suivante pour ajouter le nouveau secret d'extraction :

      $ oc registry login --registry="<registry>" \ 1
      --auth-basic="<username>:<password>" \ 2
      --to=<pull_secret_location> 3

      1

      Indiquez le nouveau registre. Vous pouvez inclure plusieurs référentiels dans le même registre, par exemple : --registry="<registry/my-namespace/my-repository>".

      2

      Fournir les informations d'identification du nouveau registre.

      3

      Indiquer le chemin d'accès au fichier de secret d'extraction.

      Vous pouvez également procéder à une mise à jour manuelle du fichier "pull secret".

2. Entrez la commande suivante pour mettre à jour le secret d'extraction global pour votre cluster :

   oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=<pull_secret_location> 1

   1

   Indiquez le chemin d'accès au nouveau fichier de secret d'extraction.

   Cette mise à jour est déployée sur tous les nœuds, ce qui peut prendre un certain temps en fonction de la taille de votre cluster.

   Note

   Depuis OpenShift Container Platform 4.7.4, les modifications apportées au secret de tirage global ne déclenchent plus la vidange ou le redémarrage d'un nœud.

Procédure

1. Naviguez jusqu'à https://console.redhat.com/openshift/downloads.

2. Dans Tokens → Pull Secret, cliquez sur Download.

   Le fichier pull-secret.txt contenant votre jeton d'accès cloud.openshift.com au format JSON se télécharge :

   {
     "auths": {
       "cloud.openshift.com": {
         "auth": "<your_token>",
         "email": "<email_address>"
       }
   }

3. Téléchargez le secret d'extraction du cluster global sur votre système de fichiers local.

   $ oc get secret/pull-secret -n openshift-config --template='{{index .data ".dockerconfigjson" | base64decode}}' > pull-secret

4. Faites une copie de sauvegarde de votre secret de fabrication.

   $ cp pull-secret pull-secret-backup

5. Ouvrez le fichier pull-secret dans un éditeur de texte.
6. Ajouter l'entrée JSON cloud.openshift.com de pull-secret.txt à auths.
7. Enregistrer le fichier.

8. Mettez à jour le secret dans votre cluster.

   oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=pull-secret

Vérification

1. Naviguez jusqu'à la page OpenShift Container Platform Web Console Overview (Aperçu de la console Web OpenShift Container Platform).
2. Insights dans la tuile Status indique le nombre de problèmes trouvés.

Procédure

1. Naviguez vers Advisor → Recommendations sur OpenShift Cluster Manager Hybrid Cloud Console.

   En fonction du résultat, Insights Advisor affiche l'un des éléments suivants :

   • No matching recommendations foundsi Insights n'a pas identifié de problèmes.
   • Liste des problèmes détectés par Insights, classés par risque (faible, modéré, important et critique).
   • No clusters yetsi Insights n'a pas encore analysé le cluster. L'analyse commence peu après l'installation, l'enregistrement et la connexion à Internet de la grappe.

2. Si des problèmes sont affichés, cliquez sur l'icône > en face de l'entrée pour obtenir plus de détails.

   En fonction du problème, les détails peuvent également contenir un lien vers plus d'informations de Red Hat sur le problème.

Procédure

1. Naviguez vers Advisor → Recommendations sur OpenShift Cluster Manager Hybrid Cloud Console.

2. Cliquez sur les icônes X à côté des filtres Clusters Impacted et Status.

   Vous pouvez maintenant parcourir toutes les recommandations potentielles pour votre cluster.

Procédure

1. Naviguez vers Advisor → Recommendations sur OpenShift Cluster Manager Hybrid Cloud Console.
2. Cliquez sur le nom de la recommandation à désactiver. Vous êtes redirigé vers la page de la recommandation unique.

3. Pour désactiver la recommandation pour un seul cluster :

   1. Cliquez sur le menu Options pour ce cluster, puis cliquez sur Disable recommendation for cluster.
   2. Saisissez une note de justification et cliquez sur Save.

4. Pour désactiver la recommandation pour tous vos clusters :

   1. Cliquez sur Actions → Disable recommendation.
   2. Saisissez une note de justification et cliquez sur Save.

Procédure

1. Naviguez vers Advisor → Recommendations sur OpenShift Cluster Manager Hybrid Cloud Console.
2. Filtrer les recommandations par Status → Disabled.
3. Localisez la recommandation à activer.
4. Cliquez sur le menu Options puis cliquez sur Enable recommendation.

Procédure

1. Naviguez vers Home → Overview dans la console web de OpenShift Container Platform.

2. Cliquez sur Insights sur la carte Status.

   La fenêtre contextuelle répertorie les problèmes potentiels regroupés par risque. Cliquez sur les catégories individuelles ou sur View all recommendations in Insights Advisor pour afficher plus de détails.

1. Naviguez jusqu'à Workloads → Secrets.
2. Sur la page Secrets, sélectionnez All Projects dans la liste Project, puis activez Show default projects.
3. Sélectionnez le projet openshift-config dans la liste Projects.
4. Recherchez le secret support dans le champ Search by name. Si le secret n'existe pas, cliquez sur Create → Key/value secret pour le créer.
5. Cliquez sur le menu Options puis cliquez sur Edit Secret.
6. Cliquez sur Add Key/Value.
7. Saisissez disableInsightsAlerts comme clé avec la valeur True, et cliquez sur Save.

Procédure

1. Recherchez le nom du module en cours d'exécution pour l'opérateur Insights :

   $ oc get pods --namespace=openshift-insights -o custom-columns=:metadata.name --no-headers  --field-selector=status.phase=Running

2. Copier les archives de données récentes collectées par l'opérateur Insights :

   oc cp openshift-insights/<insights_operator_pod_name>:/var/lib/insights-operator ./insights-data 1

   1

   Remplacez <insights_operator_pod_name> par le nom du pod résultant de la commande précédente.

Procédure

1. Depuis votre archive, ouvrez /insights-operator/gathers.json.

   Le fichier contient une liste des opérations de collecte de l'opérateur Insights :

       {
         "name": "clusterconfig/authentication",
         "duration_in_ms": 730, 1
         "records_count": 1,
         "errors": null,
         "panic": null
       }

   1

   duration_in_ms est le temps en millisecondes pour chaque opération de collecte.

2. Vérifier que chaque opération de rassemblement ne présente pas d'anomalie.

Procédure

1. Naviguez jusqu'à Administration → CustomResourceDefinitions.
2. Sur la page CustomResourceDefinitions, utilisez le champ Search by name pour trouver la définition de la ressource InsightsDataGather et cliquez dessus.
3. Sur la page CustomResourceDefinition details, cliquez sur l'onglet Instances.
4. Cliquez sur cluster, puis sur l'onglet YAML.

5. Pour désactiver toutes les opérations de collecte, modifiez le fichier de configuration InsightsDataGather:

   apiVersion: config.openshift.io/v1alpha1
   kind: InsightsDataGather
   metadata:
   ....
   
   spec: 1
     gatherConfig:
       disabledGatherers:
         - all 2

   1

   Le paramètre spec spécifie les configurations de rassemblement.

   2

   La valeur all désactive toutes les opérations de collecte.

   Pour désactiver certaines opérations de collecte, saisissez leur valeur sous la touche disabledGatherers:

   spec:
     gatherConfig:
       disabledGatherers:
         - clusterconfig/container_images 1
         - clusterconfig/host_subnets
         - workloads/workload_info

   1

   Exemple d'opération de collecte individuelle

6. Cliquez sur Save.

   Après avoir enregistré les modifications, les configurations de rassemblement de l'opérateur Insights sont mises à jour et les opérations ne se produisent plus.

Procédure

1. Naviguez jusqu'à Workloads → Secrets.
2. Sur la page Secrets, sélectionnez All Projects dans la liste Project, puis activez Show default projects.
3. Sélectionnez le projet openshift-config dans la liste Project.
4. Recherchez le secret support dans le champ Search by name. S'il n'existe pas, cliquez sur Create → Key/value secret pour le créer.
5. Cliquez sur le menu Options pour le secret, puis cliquez sur Edit Secret.
6. Cliquez sur Add Key/Value.
7. Saisissez un nom d'attribut avec une valeur appropriée (voir tableau ci-dessus) et cliquez sur Save.
8. Répétez les étapes ci-dessus pour toute configuration supplémentaire.

Procédure

1. Créez un fichier nommé gather-job.yaml en utilisant ce modèle :

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: insights-operator-job
     annotations:
       config.openshift.io/inject-proxy: insights-operator
   spec:
     backoffLimit: 6
     ttlSecondsAfterFinished: 600
     template:
       spec:
         restartPolicy: OnFailure
         serviceAccountName: operator
         nodeSelector:
           beta.kubernetes.io/os: linux
           node-role.kubernetes.io/master: ""
         tolerations:
         - effect: NoSchedule
           key: node-role.kubernetes.io/master
           operator: Exists
         - effect: NoExecute
           key: node.kubernetes.io/unreachable
           operator: Exists
           tolerationSeconds: 900
         - effect: NoExecute
           key: node.kubernetes.io/not-ready
           operator: Exists
           tolerationSeconds: 900
         volumes:
         - name: snapshots
           emptyDir: {}
         - name: service-ca-bundle
           configMap:
             name: service-ca-bundle
             optional: true
         initContainers:
         - name: insights-operator
           image: quay.io/openshift/origin-insights-operator:latest
           terminationMessagePolicy: FallbackToLogsOnError
           volumeMounts:
           - name: snapshots
             mountPath: /var/lib/insights-operator
           - name: service-ca-bundle
             mountPath: /var/run/configmaps/service-ca-bundle
             readOnly: true
           ports:
           - containerPort: 8443
             name: https
           resources:
             requests:
               cpu: 10m
               memory: 70Mi
           args:
           - gather
           - -v=4
           - --config=/etc/insights-operator/server.yaml
         containers:
           - name: sleepy
             image: quay.io/openshift/origin-base:latest
             args:
               - /bin/sh
               - -c
               - sleep 10m
             volumeMounts: [{name: snapshots, mountPath: /var/lib/insights-operator}]

2. Copiez votre version de l'image insights-operator:

   $ oc get -n openshift-insights deployment insights-operator -o yaml

3. Collez votre version de l'image dans gather-job.yaml:

   initContainers:
         - name: insights-operator
           image: <your_insights_operator_image_version>
           terminationMessagePolicy: FallbackToLogsOnError
           volumeMounts:

4. Créer le travail de collecte :

   $ oc apply -n openshift-insights -f gather-job.yaml

5. Recherchez le nom de l'unité d'emploi :

   $ oc describe -n openshift-insights job/insights-operator-job

   Exemple de sortie

   Events:
     Type    Reason            Age    From            Message
     ----    ------            ----   ----            -------
     Normal  SuccessfulCreate  7m18s  job-controller  Created pod: insights-operator-job-<your_job>

   où insights-operator-job-<your_job> est le nom du module.

6. Vérifiez que l'opération est terminée :

   oc logs -n openshift-insights insights-operator-job-<your_job> insights-operator

   Exemple de sortie

   I0407 11:55:38.192084       1 diskrecorder.go:34] Wrote 108 records to disk in 33ms

7. Sauvegarder l'archive créée :

   $ oc cp openshift-insights/insights-operator-job-<your_job>:/var/lib/insights-operator ./insights-data

8. Nettoyer le travail :

   $ oc delete -n openshift-insights job insights-operator-job

Procédure

1. Téléchargez le fichier dockerconfig.json:

   $ oc extract secret/pull-secret -n openshift-config --to=.

2. Copiez votre jeton "cloud.openshift.com" "auth" dans le fichier dockerconfig.json:

   {
     "auths": {
       "cloud.openshift.com": {
         "auth": "<your_token>",
         "email": "asd@redhat.com"
       }
   }

3. Téléchargez l'archive sur console.redhat.com:

   $ curl -v -H \N "User-Agent : insights-operator/one10time200gather184a34f6a168926d93c330 cluster/<cluster_id>\N" -H "Authorization : Bearer <your_token>\N" -F \N "upload=@<path_to_archive>; type=application/vnd.redhat.openshift.periodic tar\N" https://console.redhat.com/api/ingress/v1/upload

   où <cluster_id> est l'identifiant de votre cluster, <your_token> est le jeton de votre secret d'extraction, et <path_to_archive> est le chemin d'accès à l'archive Insights Operator.

   Si l'opération est réussie, la commande renvoie une adresse "request_id" et "account_number":

   Exemple de sortie

   * Connection #0 to host console.redhat.com left intact
   {"request_id":"393a7cf1093e434ea8dd4ab3eb28884c","upload":{"account_number":"6274079"}}%

Verification steps

1. Connectez-vous à https://console.redhat.com/openshift.
2. Cliquez sur le menu Clusters dans le volet gauche.
3. Pour afficher les détails du cluster, cliquez sur le nom du cluster.

4. Ouvrez l'onglet Insights Advisor du cluster.

   Si le téléchargement a réussi, l'onglet affiche l'un des éléments suivants :

   • Your cluster passed all recommendationssi le conseiller Insights n'a pas identifié de problème.
   • Liste des problèmes détectés par Insights Advisor, classés par ordre de priorité en fonction du risque (faible, modéré, important et critique).

Procédure

1. Naviguez jusqu'à Workloads → Secrets.
2. Sélectionnez le projet openshift-config.
3. Recherchez le secret support dans le champ Search by name. S'il n'existe pas, cliquez sur Create → Key/value secret pour le créer.
4. Cliquez sur le menu Options puis cliquez sur Edit Secret.
5. Cliquez sur Add Key/Value.
6. Créez une clé nommée enableGlobalObfuscation avec une valeur de true, et cliquez sur Save.
7. Naviguez vers Workloads → Pods
8. Sélectionnez le projet openshift-insights.
9. Trouvez la nacelle insights-operator.
10. Pour redémarrer le pod insights-operator, cliquez sur le menu Options puis cliquez sur Delete Pod.

Vérification

1. Naviguez jusqu'à Workloads → Secrets.
2. Sélectionnez le projet openshift-insights.
3. Recherchez le secret obfuscation-translation-table en utilisant le champ Search by name.

Procédure

1. Naviguez jusqu'à Workloads → Secrets.
2. Sélectionnez le projet openshift-config.
3. Recherchez le secret support dans le champ Search by name. S'il n'existe pas, cliquez sur Create → Key/value secret pour le créer.
4. Cliquez sur le menu Options puis cliquez sur Edit Secret.
5. Cliquez sur Add Key/Value.

6. Créez une clé nommée scaInterval avec une valeur de 1h, et cliquez sur Save.

   Note

   L'intervalle 1h peut également être saisi comme 60m pour 60 minutes.

Procédure

1. Naviguez jusqu'à Workloads → Secrets.
2. Sélectionnez le projet openshift-config.
3. Recherchez le secret support dans le champ Search by name. S'il n'existe pas, cliquez sur Create → Key/value secret pour le créer.
4. Cliquez sur le menu Options puis cliquez sur Edit Secret.
5. Cliquez sur Add Key/Value.

6. Créez une clé nommée scaPullDisabled avec une valeur de true, et cliquez sur Save.

   L'importation des droits d'accès au contenu simple est désormais désactivée.

   Note

   Pour réactiver l'importation de contenu simple, modifiez le secret support et supprimez la clé scaPullDisabled.

Procédure

1. Accédez au répertoire dans lequel vous souhaitez stocker les données must-gather.

   Note

   Si votre cluster utilise un réseau restreint, vous devez prendre des mesures supplémentaires. Si votre registre miroir dispose d'une autorité de certification approuvée, vous devez d'abord ajouter cette dernière au cluster. Pour tous les clusters sur des réseaux restreints, vous devez importer l'image par défaut must-gather en tant que flux d'images.

   $ oc import-image is/must-gather -n openshift

2. Exécutez la commande oc adm must-gather:

   $ oc adm must-gather

   Note

   Comme cette commande choisit un nœud de plan de contrôle aléatoire par défaut, le pod peut être programmé sur un nœud de plan de contrôle qui se trouve dans l'état NotReady et SchedulingDisabled.

   1. Si cette commande échoue, par exemple si vous ne pouvez pas planifier un pod sur votre cluster, utilisez la commande oc adm inspect pour recueillir des informations sur des ressources particulières.

      Note

      Contactez l'assistance de Red Hat pour connaître les ressources recommandées à rassembler.

3. Créez un fichier compressé à partir du répertoire must-gather qui vient d'être créé dans votre répertoire de travail. Par exemple, sur un ordinateur utilisant un système d'exploitation Linux, exécutez la commande suivante :

   $ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ 1

   1

   Veillez à remplacer must-gather-local.5421342344627712289/ par le nom réel du répertoire.

4. Joignez le fichier compressé à votre demande d'assistance sur le portail client de Red Hat.

Procédure

1. Accédez au répertoire dans lequel vous souhaitez stocker les données must-gather.

2. Exécutez la commande oc adm must-gather avec un ou plusieurs arguments --image ou --image-stream. Par exemple, la commande suivante rassemble à la fois les données de cluster par défaut et les informations spécifiques à OpenShift Virtualization :

   $ oc adm must-gather \
    --image-stream=openshift/must-gather \ 1
    --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.12.2 2

   1

   L'image par défaut d'OpenShift Container Platform must-gather

   2

   L'image indispensable pour OpenShift Virtualization

   Vous pouvez utiliser l'outil must-gather avec des arguments supplémentaires pour rassembler des données qui sont spécifiquement liées à OpenShift Logging et à l'opérateur Red Hat OpenShift Logging dans votre cluster. Pour OpenShift Logging, exécutez la commande suivante :

   $ oc adm must-gather --image=$(oc -n openshift-logging get deployment.apps/cluster-logging-operator \
    -o jsonpath='{.spec.template.spec.containers[?(@.name == "cluster-logging-operator")].image}')

   Exemple 5.1. Exemple de sortie must-gather pour OpenShift Logging

   ├── cluster-logging
   │  ├── clo
   │  │  ├── cluster-logging-operator-74dd5994f-6ttgt
   │  │  ├── clusterlogforwarder_cr
   │  │  ├── cr
   │  │  ├── csv
   │  │  ├── deployment
   │  │  └── logforwarding_cr
   │  ├── collector
   │  │  ├── fluentd-2tr64
   │  ├── eo
   │  │  ├── csv
   │  │  ├── deployment
   │  │  └── elasticsearch-operator-7dc7d97b9d-jb4r4
   │  ├── es
   │  │  ├── cluster-elasticsearch
   │  │  │  ├── aliases
   │  │  │  ├── health
   │  │  │  ├── indices
   │  │  │  ├── latest_documents.json
   │  │  │  ├── nodes
   │  │  │  ├── nodes_stats.json
   │  │  │  └── thread_pool
   │  │  ├── cr
   │  │  ├── elasticsearch-cdm-lp8l38m0-1-794d6dd989-4jxms
   │  │  └── logs
   │  │     ├── elasticsearch-cdm-lp8l38m0-1-794d6dd989-4jxms
   │  ├── install
   │  │  ├── co_logs
   │  │  ├── install_plan
   │  │  ├── olmo_logs
   │  │  └── subscription
   │  └── kibana
   │     ├── cr
   │     ├── kibana-9d69668d4-2rkvz
   ├── cluster-scoped-resources
   │  └── core
   │     ├── nodes
   │     │  ├── ip-10-0-146-180.eu-west-1.compute.internal.yaml
   │     └── persistentvolumes
   │        ├── pvc-0a8d65d9-54aa-4c44-9ecc-33d9381e41c1.yaml
   ├── event-filter.html
   ├── gather-debug.log
   └── namespaces
      ├── openshift-logging
      │  ├── apps
      │  │  ├── daemonsets.yaml
      │  │  ├── deployments.yaml
      │  │  ├── replicasets.yaml
      │  │  └── statefulsets.yaml
      │  ├── batch
      │  │  ├── cronjobs.yaml
      │  │  └── jobs.yaml
      │  ├── core
      │  │  ├── configmaps.yaml
      │  │  ├── endpoints.yaml
      │  │  ├── events
      │  │  │  ├── elasticsearch-im-app-1596020400-gm6nl.1626341a296c16a1.yaml
      │  │  │  ├── elasticsearch-im-audit-1596020400-9l9n4.1626341a2af81bbd.yaml
      │  │  │  ├── elasticsearch-im-infra-1596020400-v98tk.1626341a2d821069.yaml
      │  │  │  ├── elasticsearch-im-app-1596020400-cc5vc.1626341a3019b238.yaml
      │  │  │  ├── elasticsearch-im-audit-1596020400-s8d5s.1626341a31f7b315.yaml
      │  │  │  ├── elasticsearch-im-infra-1596020400-7mgv8.1626341a35ea59ed.yaml
      │  │  ├── events.yaml
      │  │  ├── persistentvolumeclaims.yaml
      │  │  ├── pods.yaml
      │  │  ├── replicationcontrollers.yaml
      │  │  ├── secrets.yaml
      │  │  └── services.yaml
      │  ├── openshift-logging.yaml
      │  ├── pods
      │  │  ├── cluster-logging-operator-74dd5994f-6ttgt
      │  │  │  ├── cluster-logging-operator
      │  │  │  │  └── cluster-logging-operator
      │  │  │  │     └── logs
      │  │  │  │        ├── current.log
      │  │  │  │        ├── previous.insecure.log
      │  │  │  │        └── previous.log
      │  │  │  └── cluster-logging-operator-74dd5994f-6ttgt.yaml
      │  │  ├── cluster-logging-operator-registry-6df49d7d4-mxxff
      │  │  │  ├── cluster-logging-operator-registry
      │  │  │  │  └── cluster-logging-operator-registry
      │  │  │  │     └── logs
      │  │  │  │        ├── current.log
      │  │  │  │        ├── previous.insecure.log
      │  │  │  │        └── previous.log
      │  │  │  ├── cluster-logging-operator-registry-6df49d7d4-mxxff.yaml
      │  │  │  └── mutate-csv-and-generate-sqlite-db
      │  │  │     └── mutate-csv-and-generate-sqlite-db
      │  │  │        └── logs
      │  │  │           ├── current.log
      │  │  │           ├── previous.insecure.log
      │  │  │           └── previous.log
      │  │  ├── elasticsearch-cdm-lp8l38m0-1-794d6dd989-4jxms
      │  │  ├── elasticsearch-im-app-1596030300-bpgcx
      │  │  │  ├── elasticsearch-im-app-1596030300-bpgcx.yaml
      │  │  │  └── indexmanagement
      │  │  │     └── indexmanagement
      │  │  │        └── logs
      │  │  │           ├── current.log
      │  │  │           ├── previous.insecure.log
      │  │  │           └── previous.log
      │  │  ├── fluentd-2tr64
      │  │  │  ├── fluentd
      │  │  │  │  └── fluentd
      │  │  │  │     └── logs
      │  │  │  │        ├── current.log
      │  │  │  │        ├── previous.insecure.log
      │  │  │  │        └── previous.log
      │  │  │  ├── fluentd-2tr64.yaml
      │  │  │  └── fluentd-init
      │  │  │     └── fluentd-init
      │  │  │        └── logs
      │  │  │           ├── current.log
      │  │  │           ├── previous.insecure.log
      │  │  │           └── previous.log
      │  │  ├── kibana-9d69668d4-2rkvz
      │  │  │  ├── kibana
      │  │  │  │  └── kibana
      │  │  │  │     └── logs
      │  │  │  │        ├── current.log
      │  │  │  │        ├── previous.insecure.log
      │  │  │  │        └── previous.log
      │  │  │  ├── kibana-9d69668d4-2rkvz.yaml
      │  │  │  └── kibana-proxy
      │  │  │     └── kibana-proxy
      │  │  │        └── logs
      │  │  │           ├── current.log
      │  │  │           ├── previous.insecure.log
      │  │  │           └── previous.log
      │  └── route.openshift.io
      │     └── routes.yaml
      └── openshift-operators-redhat
         ├── ...

3. Exécutez la commande oc adm must-gather avec un ou plusieurs arguments --image ou --image-stream. Par exemple, la commande suivante rassemble à la fois les données du cluster par défaut et les informations spécifiques à KubeVirt :

   $ oc adm must-gather \
    --image-stream=openshift/must-gather \ 1
    --image=quay.io/kubevirt/must-gather 2

   1

   L'image par défaut d'OpenShift Container Platform must-gather

   2

   L'image obligatoire pour KubeVirt

4. Créez un fichier compressé à partir du répertoire must-gather qui vient d'être créé dans votre répertoire de travail. Par exemple, sur un ordinateur utilisant un système d'exploitation Linux, exécutez la commande suivante :

   $ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ 1

   1

   Veillez à remplacer must-gather-local.5421342344627712289/ par le nom réel du répertoire.

5. Joignez le fichier compressé à votre demande d'assistance sur le portail client de Red Hat.

Procédure

1. Exécutez la commande oc adm must-gather avec -- /usr/bin/gather_audit_logs:

   $ oc adm must-gather -- /usr/bin/gather_audit_logs

2. Créez un fichier compressé à partir du répertoire must-gather qui vient d'être créé dans votre répertoire de travail. Par exemple, sur un ordinateur utilisant un système d'exploitation Linux, exécutez la commande suivante :

   $ tar cvaf must-gather.tar.gz must-gather.local.472290403699006248 1

   1

   Remplacez must-gather-local.472290403699006248 par le nom du répertoire.

3. Joignez le fichier compressé à votre demande d'assistance sur le portail client de Red Hat.

Procédure

1. Exécutez la commande oc adm must-gather avec -- gather_network_logs:

   $ oc adm must-gather -- gather_network_logs

2. Créez un fichier compressé à partir du répertoire must-gather qui vient d'être créé dans votre répertoire de travail. Par exemple, sur un ordinateur utilisant un système d'exploitation Linux, exécutez la commande suivante :

   $ tar cvaf must-gather.tar.gz must-gather.local.472290403699006248 1

   1

   Remplacez must-gather-local.472290403699006248 par le nom du répertoire.

3. Joignez le fichier compressé à votre demande d'assistance sur le portail client de Red Hat.

1. Les fichiers de configuration d'Ignition sont créés.
2. La machine d'amorçage démarre et commence à héberger les ressources distantes nécessaires au démarrage des machines du plan de contrôle.
3. Les machines du plan de contrôle récupèrent les ressources distantes de la machine d'amorçage et terminent le démarrage.
4. Les machines du plan de contrôle utilisent la machine bootstrap pour former un cluster etcd.
5. La machine d'amorçage démarre un plan de contrôle Kubernetes temporaire en utilisant le nouveau cluster etcd.
6. Le plan de contrôle temporaire planifie le plan de contrôle de production sur les machines du plan de contrôle.
7. Le plan de contrôle temporaire s'arrête et passe le contrôle au plan de contrôle de production.
8. La machine d'amorçage ajoute des composants OpenShift Container Platform dans le plan de contrôle de la production.
9. Le programme d'installation arrête la machine de démarrage.
10. Le plan de contrôle met en place les nœuds de travail.
11. Le plan de contrôle installe des services supplémentaires sous la forme d'un ensemble d'opérateurs.
12. Le cluster télécharge et configure les autres composants nécessaires au fonctionnement quotidien, y compris la création de machines de travail dans les environnements pris en charge.

Procédure

1. Vérifiez que le service haproxy systemd est actif :

   $ ssh <user_name>@<load_balancer> systemctl status haproxy

2. Vérifiez que l'équilibreur de charge écoute sur les ports requis. L'exemple suivant fait référence aux ports 80, 443, 6443 et 22623.

   • Pour les instances HAProxy fonctionnant sous Red Hat Enterprise Linux (RHEL) 6, vérifiez l'état des ports à l'aide de la commande netstat:

     $ ssh <user_name>@<load_balancer> netstat -nltupe | grep -E ':80|:443|:6443|:22623'

   • Pour les instances HAProxy fonctionnant sous Red Hat Enterprise Linux (RHEL) 7 ou 8, vérifiez l'état des ports à l'aide de la commande ss:

     $ ssh <user_name>@<load_balancer> ss -nltupe | grep -E ':80|:443|:6443|:22623'

     Note

     Red Hat recommande la commande ss au lieu de netstat dans Red Hat Enterprise Linux (RHEL) 7 ou une version ultérieure. ss est fourni par le paquetage iproute. Pour plus d'informations sur la commande ss, consultez le Guide d'optimisation des performances de Red Hat Enterprise Linux (RHEL) 7.

3. Vérifiez que l'enregistrement DNS générique se résout vers l'équilibreur de charge :

   $ dig <wildcard_fqdn> @<dns_server>

Procédure

1. Observez le journal d'installation au fur et à mesure que l'installation progresse :

   $ tail -f ~/<installation_directory>/.openshift_install.log

2. Surveillez le journal bootkube.service journald unit log sur le nœud d'amorçage, après qu'il ait démarré. Cela permet d'avoir une visibilité sur le démarrage du premier plan de contrôle. Remplacez <bootstrap_fqdn> par le nom de domaine complet du nœud d'amorçage :

   $ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service

   Note

   The bootkube.service log on the bootstrap node outputs etcd connection refused errors, indicating that the bootstrap server is unable to connect to etcd on control plane nodes. After etcd has started on each control plane node and the nodes have joined the cluster, the errors should stop.

3. Surveillez les journaux de l'unité kubelet.service journald sur les nœuds du plan de contrôle, après leur démarrage. Cela permet d'avoir une visibilité sur l'activité des agents des nœuds du plan de contrôle.

   1. Surveillez les journaux à l'aide de oc:

      $ oc adm node-logs --role=master -u kubelet

   2. Si l'API n'est pas fonctionnelle, examinez les journaux en utilisant SSH à la place. Remplacez <master-node>.<cluster_name>.<base_domain> par les valeurs appropriées :

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

4. Surveillez les journaux de l'unité crio.service journald sur les nœuds du plan de contrôle, après leur démarrage. Cela permet d'avoir une visibilité sur l'activité d'exécution des conteneurs CRI-O sur les nœuds du plan de contrôle.

   1. Surveillez les journaux à l'aide de oc:

      $ oc adm node-logs --role=master -u crio

   2. Si l'API n'est pas fonctionnelle, examinez les journaux en utilisant SSH à la place. Remplacez <master-node>.<cluster_name>.<base_domain> par les valeurs appropriées :

      $ ssh core@master-N.cluster_name.sub_domain.domain journalctl -b -f -u crio.service

Procédure

1. Si vous avez accès à la console du nœud d'amorce, surveillez la console jusqu'à ce que le nœud atteigne l'invite de connexion.

2. Vérifier la configuration du fichier Ignition.

   • Si vous hébergez les fichiers de configuration d'Ignition en utilisant un serveur HTTP.

     1. Vérifier l'URL du fichier Ignition du nœud d'amorçage. Remplacer <http_server_fqdn> par le nom de domaine complet du serveur HTTP :

        $ curl -I http://<http_server_fqdn>:<port>/bootstrap.ign  1

        1

        L'option -I renvoie uniquement l'en-tête. Si le fichier Ignition est disponible sur l'URL spécifiée, la commande renvoie l'état 200 OK. S'il n'est pas disponible, la commande renvoie l'état 404 file not found.

     2. Pour vérifier que le fichier Ignition a été reçu par le nœud d'amorçage, interrogez les journaux du serveur HTTP sur l'hôte d'accueil. Par exemple, si vous utilisez un serveur web Apache pour servir les fichiers Ignition, entrez la commande suivante :

        $ grep -is 'bootstrap.ign' /var/log/httpd/access_log

        Si le fichier Ignition bootstrap est reçu, le message de journal HTTP GET associé inclura un état de réussite 200 OK, indiquant que la demande a réussi.

     3. Si le fichier Ignition n'a pas été reçu, vérifiez que les fichiers Ignition existent et qu'ils disposent des autorisations de fichier et de serveur web appropriées sur l'hôte serveur directement.

   • Si vous utilisez un mécanisme de fournisseur de cloud pour injecter des fichiers de configuration Ignition dans les hôtes dans le cadre de leur déploiement initial.

     1. Examinez la console du nœud d'amorce pour déterminer si le mécanisme injecte correctement le fichier Ignition du nœud d'amorce.
3. Vérifier la disponibilité de l'unité de stockage assignée au nœud d'amorce.
4. Vérifiez qu'une adresse IP a été attribuée au nœud d'amorçage par le serveur DHCP.

5. Collecter les journaux de l'unité bootkube.service journald du nœud d'amorçage. Remplacez <bootstrap_fqdn> par le nom de domaine complet du nœud d'amorçage :

   $ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service

   Note

   The bootkube.service log on the bootstrap node outputs etcd connection refused errors, indicating that the bootstrap server is unable to connect to etcd on control plane nodes. After etcd has started on each control plane node and the nodes have joined the cluster, the errors should stop.

6. Collecter les journaux des conteneurs du nœud d'amorçage.

   1. Collectez les journaux en utilisant podman sur le nœud d'amorçage. Remplacez <bootstrap_fqdn> par le nom de domaine complet du nœud d'amorçage :

      $ ssh core@<bootstrap_fqdn> 'for pod in $(sudo podman ps -a -q) ; do sudo podman logs $pod ; done'

7. Si le processus d'amorçage échoue, vérifiez les points suivants.

   • Vous pouvez résoudre le problème api.<cluster_name>.<base_domain> à partir de l'hôte d'installation.
   • L'équilibreur de charge assure le proxy des connexions du port 6443 vers les nœuds d'amorçage et de plan de contrôle. Assurez-vous que la configuration du proxy est conforme aux exigences d'installation d'OpenShift Container Platform.

Procédure

1. Si vous avez accès à la console du nœud du plan de contrôle, surveillez la console jusqu'à ce que le nœud atteigne l'invite de connexion. Pendant l'installation, les messages du journal Ignition sont envoyés à la console.

2. Vérifier la configuration du fichier d'allumage.

   • Si vous hébergez les fichiers de configuration d'Ignition en utilisant un serveur HTTP.

     1. Vérifier l'URL du fichier Ignition du nœud du plan de contrôle. Remplacez <http_server_fqdn> par le nom de domaine complet du serveur HTTP :

        $ curl -I http://<http_server_fqdn>:<port>/master.ign  1

        1

        L'option -I renvoie uniquement l'en-tête. Si le fichier Ignition est disponible sur l'URL spécifiée, la commande renvoie l'état 200 OK. S'il n'est pas disponible, la commande renvoie l'état 404 file not found.

     2. Pour vérifier que le fichier Ignition a été reçu par le nœud du plan de contrôle, interrogez les journaux du serveur HTTP sur l'hôte serveur. Par exemple, si vous utilisez un serveur web Apache pour servir les fichiers Ignition :

        $ grep -is 'master.ign' /var/log/httpd/access_log

        Si le fichier maître Ignition est reçu, le message de journal HTTP GET associé inclura un état de réussite 200 OK, indiquant que la demande a réussi.

     3. Si le fichier Ignition n'a pas été reçu, vérifiez qu'il existe directement sur l'hôte serveur. Assurez-vous que les autorisations appropriées pour les fichiers et le serveur web sont en place.

   • Si vous utilisez un mécanisme de fournisseur de cloud pour injecter des fichiers de configuration Ignition dans les hôtes dans le cadre de leur déploiement initial.

     1. Examinez la console du nœud du plan de contrôle pour déterminer si le mécanisme injecte correctement le fichier d'ignition du nœud du plan de contrôle.
3. Vérifier la disponibilité de l'unité de stockage affectée au nœud du plan de contrôle.
4. Vérifiez qu'une adresse IP a été attribuée au nœud du plan de contrôle par le serveur DHCP.

5. Déterminer l'état des nœuds du plan de contrôle.

   1. Demande l'état des nœuds du plan de contrôle :

      $ oc get nodes

   2. Si l'un des nœuds du plan de contrôle n'atteint pas l'état Ready, récupérez une description détaillée du nœud :

      oc describe node <master_node>

      Note

      Il n'est pas possible d'exécuter les commandes oc si un problème d'installation empêche l'API OpenShift Container Platform de fonctionner ou si le kubelet ne fonctionne pas encore sur chaque nœud :

6. Déterminer le statut SDN de la plateforme OpenShift Container.

   1. Examinez l'état des jeux de démons sdn-controller, sdn et ovs dans l'espace de noms openshift-sdn:

      $ oc get daemonsets -n openshift-sdn

   2. Si ces ressources sont répertoriées comme Not found, examinez les pods dans l'espace de noms openshift-sdn:

      $ oc get pods -n openshift-sdn

   3. Examinez les journaux relatifs aux pods SDN de OpenShift Container Platform qui ont échoué dans l'espace de noms openshift-sdn:

      $ oc logs <sdn_pod> -n openshift-sdn

7. Déterminer l'état de la configuration du réseau de la grappe.

   1. Vérifiez si la configuration du réseau de la grappe existe :

      $ oc get network.config.openshift.io cluster -o yaml

   2. Si le programme d'installation n'a pas réussi à créer la configuration réseau, générez à nouveau les manifestes Kubernetes et examinez les messages :

      $ ./openshift-install create manifests

   3. Examinez l'état du pod dans l'espace de noms openshift-network-operator pour déterminer si le Cluster Network Operator (CNO) est en cours d'exécution :

      $ oc get pods -n openshift-network-operator

   4. Rassemble les journaux des pods de l'opérateur réseau de l'espace de noms openshift-network-operator:

      oc logs pod/<network_operator_pod_name> -n openshift-network-operator

8. Surveillez les journaux de l'unité kubelet.service journald sur les nœuds du plan de contrôle, après leur démarrage. Cela permet d'avoir une visibilité sur l'activité des agents des nœuds du plan de contrôle.

   1. Récupérez les journaux à l'aide de oc:

      $ oc adm node-logs --role=master -u kubelet

   2. Si l'API n'est pas fonctionnelle, examinez les journaux en utilisant SSH à la place. Remplacez <master-node>.<cluster_name>.<base_domain> par les valeurs appropriées :

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

      Note

      Les nœuds de cluster OpenShift Container Platform 4.12 exécutant Red Hat Enterprise Linux CoreOS (RHCOS) sont immuables et dépendent des opérateurs pour appliquer les changements de cluster. L'accès aux nœuds de cluster à l'aide de SSH n'est pas recommandé et les nœuds seront altérés comme accessed. Avant d'essayer de collecter des données de diagnostic via SSH, vérifiez si les données collectées en exécutant oc adm must gather et d'autres commandes oc sont suffisantes. Cependant, si l'API OpenShift Container Platform n'est pas disponible, ou si le kubelet ne fonctionne pas correctement sur le nœud cible, les opérations oc seront impactées. Dans de telles situations, il est possible d'accéder aux nœuds en utilisant ssh core@<node>.<cluster_name>.<base_domain>.

9. Récupérer les journaux de l'unité crio.service journald sur les nœuds du plan de contrôle, après leur démarrage. Cela permet de connaître l'activité d'exécution des conteneurs CRI-O sur les nœuds du plan de contrôle.

   1. Récupérez les journaux à l'aide de oc:

      $ oc adm node-logs --role=master -u crio

   2. Si l'API n'est pas fonctionnelle, examinez les journaux en utilisant plutôt SSH :

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service

10. Collecter les journaux dans des sous-répertoires spécifiques sous /var/log/ sur les nœuds du plan de contrôle.

    1. Récupérer la liste des journaux contenus dans un sous-répertoire /var/log/. L'exemple suivant répertorie les fichiers de /var/log/openshift-apiserver/ sur tous les nœuds du plan de contrôle :

       $ oc adm node-logs --role=master --path=openshift-apiserver

    2. Inspecter un journal spécifique dans un sous-répertoire /var/log/. L'exemple suivant affiche le contenu de /var/log/openshift-apiserver/audit.log pour tous les nœuds du plan de contrôle :

       $ oc adm node-logs --role=master --path=openshift-apiserver/audit.log

    3. Si l'API n'est pas fonctionnelle, examinez les journaux sur chaque nœud en utilisant SSH à la place. L'exemple suivant est une queue /var/log/openshift-apiserver/audit.log:

       $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/openshift-apiserver/audit.log

11. Examiner les journaux des conteneurs du nœud du plan de contrôle à l'aide de SSH.

    1. Dressez la liste des conteneurs :

       $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps -a

    2. Récupérer les journaux d'un conteneur en utilisant crictl:

       $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

12. Si vous rencontrez des problèmes de configuration des nœuds du plan de contrôle, vérifiez que le MCO, le point de terminaison MCO et l'enregistrement DNS fonctionnent. Le MCO (Machine Config Operator) gère la configuration du système d'exploitation pendant la procédure d'installation. Vérifiez également l'exactitude de l'horloge du système et la validité du certificat.

    1. Tester si le point de terminaison MCO est disponible. Remplacer <cluster_name> par les valeurs appropriées :

       $ curl https://api-int.<cluster_name>:22623/config/master

    2. Si le point d'accès ne répond pas, vérifiez la configuration de l'équilibreur de charge. Assurez-vous que le point d'accès est configuré pour fonctionner sur le port 22623.

    3. Vérifiez que l'enregistrement DNS du point d'extrémité MCO est configuré et qu'il se résout vers l'équilibreur de charge.

       1. Lancer une recherche DNS pour le nom du point de terminaison MCO défini :

          $ dig api-int.<cluster_name> @<dns_server>

       2. Effectuez une recherche inversée de l'adresse IP MCO attribuée sur l'équilibreur de charge :

          $ dig -x <load_balancer_mco_ip_address> @<dns_server>

    4. Vérifiez que le MCO fonctionne directement à partir du nœud de démarrage. Remplacez <bootstrap_fqdn> par le nom de domaine pleinement qualifié du nœud d'amorce :

       $ ssh core@<bootstrap_fqdn> curl https://api-int.<cluster_name>:22623/config/master

    5. L'heure de l'horloge système doit être synchronisée entre les nœuds de démarrage, maître et subordonné. Vérifiez l'heure de référence de l'horloge système de chaque nœud et les statistiques de synchronisation du temps :

       $ ssh core@<node>.<cluster_name>.<base_domain> chronyc tracking

    6. Examiner la validité du certificat :

       openssl s_client -connect api-int.<cluster_name>:22623 | openssl x509 -noout -text

Procédure

1. Vérifier l'état des pods etcd.

   1. Examiner l'état des pods dans l'espace de noms openshift-etcd:

      $ oc get pods -n openshift-etcd

   2. Examiner l'état des pods dans l'espace de noms openshift-etcd-operator:

      $ oc get pods -n openshift-etcd-operator

2. Si l'un des pods répertoriés par les commandes précédentes n'affiche pas un état Running ou Completed, recueillez des informations de diagnostic pour le pod.

   1. Examiner les événements pour le pod :

      oc describe pod/<nom_du_pod> -n <espace_de_noms>

   2. Inspecter les journaux de bord de la nacelle :

      oc logs pod/<nom_du_pod> -n <espace-noms>

   3. Si le pod a plus d'un conteneur, la commande précédente créera une erreur et les noms des conteneurs seront fournis dans le message d'erreur. Examinez les journaux de chaque conteneur :

      oc logs pod/<nom_du_pod> -c <nom_du_conteneur> -n <espace_de_noms>

3. Si l'API n'est pas fonctionnelle, examinez les journaux des pods et des conteneurs etcd sur chaque nœud du plan de contrôle en utilisant SSH à la place. Remplacez <master-node>.<cluster_name>.<base_domain> par les valeurs appropriées.

   1. Liste des pods etcd sur chaque nœud du plan de contrôle :

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods --name=etcd-

   2. Pour tout pod n'affichant pas l'état Ready, inspectez l'état du pod en détail. Remplacez <pod_id> par l'ID du pod indiqué dans la sortie de la commande précédente :

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <pod_id>

   3. Liste des conteneurs liés à un pod :

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps | grep '<pod_id>'

   4. Pour tous les conteneurs qui n'affichent pas le statut Ready, inspectez le statut du conteneur en détail. Remplacez <container_id> par les ID des conteneurs répertoriés dans la sortie de la commande précédente :

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>

   5. Examinez les journaux pour tous les conteneurs qui n'affichent pas le statut Ready. Remplacez <container_id> par les ID des conteneurs répertoriés dans la sortie de la commande précédente :

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

      Note

      Les nœuds de cluster OpenShift Container Platform 4.12 exécutant Red Hat Enterprise Linux CoreOS (RHCOS) sont immuables et dépendent des opérateurs pour appliquer les changements de cluster. L'accès aux nœuds de cluster à l'aide de SSH n'est pas recommandé et les nœuds seront altérés comme accessed. Avant d'essayer de collecter des données de diagnostic via SSH, vérifiez si les données collectées en exécutant oc adm must gather et d'autres commandes oc sont suffisantes. Cependant, si l'API OpenShift Container Platform n'est pas disponible, ou si le kubelet ne fonctionne pas correctement sur le nœud cible, les opérations oc seront impactées. Dans de telles situations, il est possible d'accéder aux nœuds en utilisant ssh core@<node>.<cluster_name>.<base_domain>.

4. Valider la connectivité des serveurs DNS primaire et secondaire à partir des nœuds du plan de contrôle.

Procédure

1. Vérifiez que l'enregistrement DNS du serveur API dirige le kubelet sur les nœuds du plan de contrôle vers https://api-int.<cluster_name>.<base_domain>:6443. Assurez-vous que l'enregistrement fait référence à l'équilibreur de charge.
2. Assurez-vous que la définition du port 6443 de l'équilibreur de charge fait référence à chaque nœud du plan de contrôle.
3. Vérifier que des noms d'hôtes uniques de nœuds de plan de contrôle ont été fournis par DHCP.

4. Inspectez les journaux de l'unité kubelet.service journald sur chaque nœud du plan de contrôle.

   1. Récupérez les journaux à l'aide de oc:

      $ oc adm node-logs --role=master -u kubelet

   2. Si l'API n'est pas fonctionnelle, examinez les journaux en utilisant SSH à la place. Remplacez <master-node>.<cluster_name>.<base_domain> par les valeurs appropriées :

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

      Note

      Les nœuds de cluster OpenShift Container Platform 4.12 exécutant Red Hat Enterprise Linux CoreOS (RHCOS) sont immuables et dépendent des opérateurs pour appliquer les changements de cluster. L'accès aux nœuds de cluster à l'aide de SSH n'est pas recommandé et les nœuds seront altérés comme accessed. Avant d'essayer de collecter des données de diagnostic via SSH, vérifiez si les données collectées en exécutant oc adm must gather et d'autres commandes oc sont suffisantes. Cependant, si l'API OpenShift Container Platform n'est pas disponible, ou si le kubelet ne fonctionne pas correctement sur le nœud cible, les opérations oc seront impactées. Dans de telles situations, il est possible d'accéder aux nœuds en utilisant ssh core@<node>.<cluster_name>.<base_domain>.

5. Vérifier les messages d'expiration des certificats dans les journaux des kubelets du nœud du plan de contrôle.

   1. Récupérez le journal en utilisant oc:

      $ oc adm node-logs --role=master -u kubelet | grep -is 'x509: certificate has expired'

   2. Si l'API n'est pas fonctionnelle, examinez les journaux en utilisant SSH à la place. Remplacez <master-node>.<cluster_name>.<base_domain> par les valeurs appropriées :

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service  | grep -is 'x509: certificate has expired'

Procédure

1. Si vous avez accès à la console du nœud de travail, surveillez la console jusqu'à ce que le nœud atteigne l'invite de connexion. Pendant l'installation, les messages du journal Ignition sont envoyés à la console.

2. Vérifier la configuration du fichier d'allumage.

   • Si vous hébergez les fichiers de configuration d'Ignition en utilisant un serveur HTTP.

     1. Vérifiez l'URL du fichier Ignition du nœud de travail. Remplacez <http_server_fqdn> par le nom de domaine complet du serveur HTTP :

        $ curl -I http://<http_server_fqdn>:<port>/worker.ign  1

        1

        L'option -I renvoie uniquement l'en-tête. Si le fichier Ignition est disponible sur l'URL spécifiée, la commande renvoie l'état 200 OK. S'il n'est pas disponible, la commande renvoie l'état 404 file not found.

     2. Pour vérifier que le fichier Ignition a été reçu par le nœud de travail, interrogez les journaux du serveur HTTP sur l'hôte HTTP. Par exemple, si vous utilisez un serveur web Apache pour servir les fichiers Ignition :

        $ grep -is 'worker.ign' /var/log/httpd/access_log

        Si le fichier Ignition du travailleur est reçu, le message de journal HTTP GET associé inclura un état de réussite 200 OK, indiquant que la demande a réussi.

     3. Si le fichier Ignition n'a pas été reçu, vérifiez qu'il existe directement sur l'hôte serveur. Assurez-vous que les autorisations appropriées pour les fichiers et le serveur web sont en place.

   • Si vous utilisez un mécanisme de fournisseur de cloud pour injecter des fichiers de configuration Ignition dans les hôtes dans le cadre de leur déploiement initial.

     1. Examinez la console du nœud de travail pour déterminer si le mécanisme injecte correctement le fichier Ignition du nœud de travail.
3. Vérifier la disponibilité de l'unité de stockage assignée au nœud de travail.
4. Vérifiez qu'une adresse IP a été attribuée au nœud de travail par le serveur DHCP.

5. Déterminer l'état des nœuds de travail.

   1. Demande l'état du nœud :

      $ oc get nodes

   2. Récupérer une description détaillée du nœud pour tout nœud de travailleur n'affichant pas l'état Ready:

      oc describe node <worker_node> $ oc describe node <worker_node>

      Note

      Il n'est pas possible d'exécuter les commandes oc si un problème d'installation empêche l'API OpenShift Container Platform de fonctionner ou si le kubelet ne fonctionne pas encore sur chaque nœud.

6. Contrairement aux nœuds du plan de contrôle, les nœuds de travailleur sont déployés et mis à l'échelle à l'aide de l'opérateur API Machine. Vérifiez l'état de l'opérateur API Machine.

   1. Examiner le statut du pod de l'opérateur API de la machine :

      $ oc get pods -n openshift-machine-api

   2. Si le pod Opérateur API Machine n'a pas de statut Ready, détaillez les événements du pod :

      $ oc describe pod/<machine_api_operator_pod_name> -n openshift-machine-api

   3. Inspecter les journaux du conteneur machine-api-operator. Le conteneur s'exécute dans le pod machine-api-operator:

      oc logs pod/<machine_api_operator_pod_name> -n openshift-machine-api -c machine-api-operator

   4. Inspectez également les journaux du conteneur kube-rbac-proxy. Le conteneur s'exécute également dans le pod machine-api-operator:

      oc logs pod/<machine_api_operator_pod_name> -n openshift-machine-api -c kube-rbac-proxy

7. Surveillez les journaux de l'unité kubelet.service journald sur les nœuds de travail, après leur démarrage. Cela permet d'avoir une visibilité sur l'activité des agents des nœuds de travail.

   1. Récupérez les journaux à l'aide de oc:

      $ oc adm node-logs --role=worker -u kubelet

   2. Si l'API n'est pas fonctionnelle, examinez les journaux en utilisant SSH à la place. Remplacez <worker-node>.<cluster_name>.<base_domain> par les valeurs appropriées :

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

      Note

      Les nœuds de cluster OpenShift Container Platform 4.12 exécutant Red Hat Enterprise Linux CoreOS (RHCOS) sont immuables et dépendent des opérateurs pour appliquer les changements de cluster. L'accès aux nœuds de cluster à l'aide de SSH n'est pas recommandé et les nœuds seront altérés comme accessed. Avant d'essayer de collecter des données de diagnostic via SSH, vérifiez si les données collectées en exécutant oc adm must gather et d'autres commandes oc sont suffisantes. Cependant, si l'API OpenShift Container Platform n'est pas disponible, ou si le kubelet ne fonctionne pas correctement sur le nœud cible, les opérations oc seront impactées. Dans de telles situations, il est possible d'accéder aux nœuds en utilisant ssh core@<node>.<cluster_name>.<base_domain>.

8. Récupérer les journaux de l'unité crio.service journald sur les noeuds de travail, après qu'ils aient démarré. Cela permet d'avoir une visibilité sur l'activité d'exécution des conteneurs CRI-O sur les nœuds de travail.

   1. Récupérez les journaux à l'aide de oc:

      $ oc adm node-logs --role=worker -u crio

   2. Si l'API n'est pas fonctionnelle, examinez les journaux en utilisant plutôt SSH :

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service

9. Collecte des journaux à partir de sous-répertoires spécifiques sous /var/log/ sur les nœuds de travail.

   1. Récupérer la liste des journaux contenus dans un sous-répertoire /var/log/. L'exemple suivant répertorie les fichiers contenus dans /var/log/sssd/ sur tous les nœuds de travail :

      $ oc adm node-logs --role=worker --path=sssd

   2. Inspecter un journal spécifique dans un sous-répertoire /var/log/. L'exemple suivant affiche le contenu de /var/log/sssd/audit.log à partir de tous les nœuds de travail :

      $ oc adm node-logs --role=worker --path=sssd/sssd.log

   3. Si l'API n'est pas fonctionnelle, examinez les journaux sur chaque nœud en utilisant SSH à la place. L'exemple suivant est une queue /var/log/sssd/sssd.log:

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/sssd/sssd.log

10. Examinez les journaux des conteneurs des nœuds de travail à l'aide de SSH.

    1. Dressez la liste des conteneurs :

       $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo crictl ps -a

    2. Récupérer les journaux d'un conteneur en utilisant crictl:

       $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

11. Si vous rencontrez des problèmes de configuration des nœuds de travail, vérifiez que le MCO, le point de terminaison MCO et l'enregistrement DNS fonctionnent. Le MCO (Machine Config Operator) gère la configuration du système d'exploitation pendant la procédure d'installation. Vérifiez également l'exactitude de l'horloge du système et la validité du certificat.

    1. Tester si le point de terminaison MCO est disponible. Remplacer <cluster_name> par les valeurs appropriées :

       $ curl https://api-int.<cluster_name>:22623/config/worker

    2. Si le point d'accès ne répond pas, vérifiez la configuration de l'équilibreur de charge. Assurez-vous que le point d'accès est configuré pour fonctionner sur le port 22623.

    3. Vérifiez que l'enregistrement DNS du point d'extrémité MCO est configuré et qu'il se résout vers l'équilibreur de charge.

       1. Lancer une recherche DNS pour le nom du point de terminaison MCO défini :

          $ dig api-int.<cluster_name> @<dns_server>

       2. Effectuez une recherche inversée de l'adresse IP MCO attribuée sur l'équilibreur de charge :

          $ dig -x <load_balancer_mco_ip_address> @<dns_server>

    4. Vérifiez que le MCO fonctionne directement à partir du nœud de démarrage. Remplacez <bootstrap_fqdn> par le nom de domaine pleinement qualifié du nœud d'amorce :

       $ ssh core@<bootstrap_fqdn> curl https://api-int.<cluster_name>:22623/config/worker

    5. L'heure de l'horloge système doit être synchronisée entre les nœuds de démarrage, maître et subordonné. Vérifiez l'heure de référence de l'horloge système de chaque nœud et les statistiques de synchronisation du temps :

       $ ssh core@<node>.<cluster_name>.<base_domain> chronyc tracking

    6. Examiner la validité du certificat :

       openssl s_client -connect api-int.<cluster_name>:22623 | openssl x509 -noout -text

Procédure

1. Vérifier que les opérateurs de cluster sont tous disponibles à la fin d'une installation.

   $ oc get clusteroperators

2. Vérifiez que toutes les demandes de signature de certificat (CSR) requises sont approuvées. Certains nœuds peuvent ne pas passer à l'état Ready et certains opérateurs de cluster peuvent ne pas être disponibles s'il y a des CSR en attente.

   1. Vérifiez l'état des CSR et assurez-vous que vous voyez une requête client et serveur avec l'état Pending ou Approved pour chaque machine que vous avez ajoutée au cluster :

      $ oc get csr

      Exemple de sortie

      NAME        AGE     REQUESTOR                                                                   CONDITION
      csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 1
      csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
      csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending 2
      csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
      ...

      1

      Une demande de CSR du client.

      2

      Une demande de serveur CSR.

      In this example, two machines are joining the cluster. You might see more approved CSRs in the list.

   2. If the CSRs were not approved, after all of the pending CSRs for the machines you added are in Pending status, approve the CSRs for your cluster machines:

      Note

      Étant donné que les CSR tournent automatiquement, approuvez-les dans l'heure qui suit l'ajout des machines à la grappe. Si vous ne les approuvez pas dans l'heure qui suit, les certificats tourneront et il y aura plus de deux certificats pour chaque nœud. Vous devez approuver tous ces certificats. Une fois que vous avez approuvé les CSR initiaux, les CSR des clients des nœuds suivants sont automatiquement approuvés par le cluster kube-controller-manager.

      Note

      For clusters running on platforms that are not machine API enabled, such as bare metal and other user-provisioned infrastructure, you must implement a method of automatically approving the kubelet serving certificate requests (CSRs). If a request is not approved, then the oc exec, oc rsh, and oc logs commands cannot succeed, because a serving certificate is required when the API server connects to the kubelet. Any operation that contacts the Kubelet endpoint requires this certificate approval to be in place. The method must watch for new CSRs, confirm that the CSR was submitted by the node-bootstrapper service account in the system:node or system:admin groups, and confirm the identity of the node.

      • To approve them individually, run the following command for each valid CSR:

        $ oc adm certificate approve <csr_name> 1

        1

        <csr_name> est le nom d'un CSR figurant dans la liste des CSR actuels.

      • To approve all pending CSRs, run the following command:

        $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

3. Voir les événements de l'opérateur :

   oc describe clusteroperator <nom_opérateur>

4. Examiner le statut du pod de l'opérateur dans l'espace nominatif de l'opérateur :

   oc get pods -n <operator_namespace>

5. Obtenir une description détaillée pour les pods qui n'ont pas le statut Running:

   $ oc describe pod/<operator_pod_name> -n <operator_namespace>

6. Inspecter les journaux de bord :

   oc logs pod/<operator_pod_name> -n <operator_namespace>

7. En cas de problèmes liés à l'image de la base du pod, vérifier l'état de l'image de la base.

   1. Obtenir les détails de l'image de base utilisée par un pod problématique :

      $ oc get pod -o \N "jsonpath={range .status.containerStatuses[*]}{.name}{'\t'}{.state}{'\t'}{.image}{'\n'}{end}\N" <operator_pod_name> -n <operator_namespace>

   2. Liste des informations de validation des images de base :

      $ oc adm release info <image_path>:<tag> --commits

Procédure

1. Generate the commands that are required to obtain the installation logs from the bootstrap and control plane machines:

   • If you used installer-provisioned infrastructure, change to the directory that contains the installation program and run the following command:

     ./openshift-install gather bootstrap --dir <installation_directory> $ ./openshift-install gather bootstrap --dir <installation_directory> 1

     1

     installation_directory is the directory you specified when you ran ./openshift-install create cluster. This directory contains the OpenShift Container Platform definition files that the installation program creates.

     For installer-provisioned infrastructure, the installation program stores information about the cluster, so you do not specify the hostnames or IP addresses.

   • If you used infrastructure that you provisioned yourself, change to the directory that contains the installation program and run the following command:

     $ ./openshift-install gather bootstrap --dir <installation_directory> \ 1
         --bootstrap <bootstrap_address> \ 2
         --master <master_1_address> \ 3
         --master <master_2_address> \ 4
         --master <master_3_address>" 5

     1

     For installation_directory, specify the same directory you specified when you ran ./openshift-install create cluster. This directory contains the OpenShift Container Platform definition files that the installation program creates.

     2

     <bootstrap_address> is the fully qualified domain name or IP address of the cluster’s bootstrap machine.

     3 4 5

     For each control plane, or master, machine in your cluster, replace <master_*_address> with its fully qualified domain name or IP address.

     Note

     A default cluster contains three control plane machines. List all of your control plane machines as shown, no matter how many your cluster uses.

   Exemple de sortie

   INFO Pulling debug logs from the bootstrap machine
   INFO Bootstrap gather logs captured here "<installation_directory>/log-bundle-<timestamp>.tar.gz"

   If you open a Red Hat support case about your installation failure, include the compressed logs in the case.

Procédure

1. Le kubelet est géré à l'aide d'un service systemd sur chaque nœud. Examinez l'état du kubelet en interrogeant le service systemd de kubelet dans un pod de débogage.

   1. Démarrer un pod de débogage pour un nœud :

      $ oc debug node/my-node

      Note

      Si vous exécutez oc debug sur un nœud du plan de contrôle, vous trouverez les fichiers administratifs kubeconfig dans le répertoire /etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs.

   2. Définissez /host comme répertoire racine dans le shell de débogage. Le pod de débogage monte le système de fichiers racine de l'hôte dans /host au sein du pod. En changeant le répertoire racine en /host, vous pouvez exécuter les binaires contenus dans les chemins d'exécution de l'hôte :

      # chroot /host

      Note

      Les nœuds de cluster d'OpenShift Container Platform exécutant Red Hat Enterprise Linux CoreOS (RHCOS) sont immuables et s'appuient sur les opérateurs pour appliquer les changements de cluster. L'accès aux nœuds de cluster à l'aide de SSH n'est pas recommandé et les nœuds seront altérés en tant que accessed. Cependant, si l'API OpenShift Container Platform n'est pas disponible, ou si kubelet ne fonctionne pas correctement sur le nœud cible, les opérations oc seront impactées. Dans de telles situations, il est possible d'accéder aux nœuds en utilisant ssh core@<node>.<cluster_name>.<base_domain> à la place.

   3. Vérifiez si le service kubelet systemd est actif sur le nœud :

      # systemctl is-active kubelet

   4. Affiche un résumé plus détaillé de l'état de kubelet.service:

      # systemctl status kubelet

Procédure

1. Requête kubelet journald journaux d'unité des nœuds de cluster OpenShift Container Platform. L'exemple suivant interroge uniquement les nœuds du plan de contrôle :

   $ oc adm node-logs --role=master -u kubelet  1

   1

   Remplacer kubelet le cas échéant pour interroger d'autres journaux d'unité.

2. Collecte des journaux à partir de sous-répertoires spécifiques sous /var/log/ sur les nœuds de la grappe.

   1. Récupérer la liste des journaux contenus dans un sous-répertoire /var/log/. L'exemple suivant répertorie les fichiers de /var/log/openshift-apiserver/ sur tous les nœuds du plan de contrôle :

      $ oc adm node-logs --role=master --path=openshift-apiserver

   2. Inspecter un journal spécifique dans un sous-répertoire /var/log/. L'exemple suivant affiche le contenu de /var/log/openshift-apiserver/audit.log pour tous les nœuds du plan de contrôle :

      $ oc adm node-logs --role=master --path=openshift-apiserver/audit.log

   3. Si l'API n'est pas fonctionnelle, examinez les journaux sur chaque nœud en utilisant SSH à la place. L'exemple suivant est une queue /var/log/openshift-apiserver/audit.log:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/openshift-apiserver/audit.log

      Note

      Les nœuds de cluster OpenShift Container Platform 4.12 exécutant Red Hat Enterprise Linux CoreOS (RHCOS) sont immuables et dépendent des opérateurs pour appliquer les changements de cluster. L'accès aux nœuds de cluster à l'aide de SSH n'est pas recommandé et les nœuds seront altérés comme accessed. Avant d'essayer de collecter des données de diagnostic via SSH, vérifiez si les données collectées en exécutant oc adm must gather et d'autres commandes oc sont suffisantes. Cependant, si l'API OpenShift Container Platform n'est pas disponible, ou si le kubelet ne fonctionne pas correctement sur le nœud cible, les opérations oc seront impactées. Dans de telles situations, il est possible d'accéder aux nœuds en utilisant ssh core@<node>.<cluster_name>.<base_domain>.

Procédure

1. Examinez l'état du CRI-O en interrogeant le service crio systemd sur un nœud, à l'intérieur d'un pod de débogage.

   1. Démarrer un pod de débogage pour un nœud :

      $ oc debug node/my-node

   2. Définissez /host comme répertoire racine dans le shell de débogage. Le pod de débogage monte le système de fichiers racine de l'hôte dans /host au sein du pod. En changeant le répertoire racine en /host, vous pouvez exécuter les binaires contenus dans les chemins d'exécution de l'hôte :

      # chroot /host

      Note

      Les nœuds de cluster OpenShift Container Platform 4.12 exécutant Red Hat Enterprise Linux CoreOS (RHCOS) sont immuables et s'appuient sur les opérateurs pour appliquer les changements de cluster. L'accès aux nœuds de cluster à l'aide de SSH n'est pas recommandé et les nœuds seront altérés en tant que accessed. Cependant, si l'API OpenShift Container Platform n'est pas disponible, ou si le kubelet ne fonctionne pas correctement sur le nœud cible, les opérations oc seront impactées. Dans de telles situations, il est possible d'accéder aux nœuds en utilisant ssh core@<node>.<cluster_name>.<base_domain> à la place.

   3. Vérifiez si le service crio systemd est actif sur le nœud :

      # systemctl is-active crio

   4. Affiche un résumé plus détaillé de l'état de crio.service:

      # systemctl status crio.service

Procédure

1. Rassembler les journaux de l'unité CRI-O journald. L'exemple suivant collecte les journaux de tous les nœuds du plan de contrôle (au sein de la grappe) :

   $ oc adm node-logs --role=master -u crio

2. Rassemble les journaux de l'unité CRI-O journald d'un nœud spécifique :

   $ oc adm node-logs <node_name> -u crio

3. Si l'API n'est pas fonctionnelle, examinez les journaux en utilisant SSH à la place. Remplacez <node>.<cluster_name>.<base_domain> par les valeurs appropriées :

   $ ssh core@<node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service

   Note

   Les nœuds de cluster OpenShift Container Platform 4.12 exécutant Red Hat Enterprise Linux CoreOS (RHCOS) sont immuables et dépendent des opérateurs pour appliquer les changements de cluster. L'accès aux nœuds de cluster à l'aide de SSH n'est pas recommandé et les nœuds seront altérés comme accessed. Avant d'essayer de collecter des données de diagnostic via SSH, vérifiez si les données collectées en exécutant oc adm must gather et d'autres commandes oc sont suffisantes. Cependant, si l'API OpenShift Container Platform n'est pas disponible, ou si le kubelet ne fonctionne pas correctement sur le nœud cible, les opérations oc seront impactées. Dans de telles situations, il est possible d'accéder aux nœuds en utilisant ssh core@<node>.<cluster_name>.<base_domain>.

Procédure

1. Utiliser cordon sur le nœud. Cela permet d'éviter qu'une charge de travail ne soit planifiée si le nœud passe à l'état Ready. Vous saurez que la planification est désactivée lorsque SchedulingDisabled apparaîtra dans votre section Statut :

   $ oc adm cordon <nodename>

2. Drainer le nœud en tant qu'utilisateur cluster-admin :

   oc adm drain <nodename> --ignore-daemonsets --delete-emptydir-data

   Note

   L'attribut terminationGracePeriodSeconds d'un pod ou d'un modèle de pod contrôle la période de terminaison gracieuse. Cet attribut est fixé par défaut à 30 secondes, mais peut être personnalisé par application si nécessaire. S'il est fixé à plus de 90 secondes, le module peut être marqué comme SIGKILLed et ne pas se terminer avec succès.

3. Lorsque le nœud revient, connectez-vous à nouveau au nœud via SSH ou la console. Ensuite, connectez-vous à l'utilisateur root :

   $ ssh core@node1.example.com
   $ sudo -i

4. Arrêter manuellement le kubelet :

   # systemctl stop kubelet

5. Arrêter les conteneurs et les cosses :

   1. Utilisez la commande suivante pour arrêter les pods qui ne se trouvent pas dans le site HostNetwork. Ils doivent être supprimés en premier car leur suppression dépend des pods du plugin de mise en réseau, qui se trouvent dans le site HostNetwork.

      .. for pod in $(crictl pods -q); do if [[ "$(crictl inspectp $pod | jq -r .status.linux.namespaces.options.network)" != "NODE" ]]; then crictl rmp -f $pod; fi; done

   2. Arrêter toutes les autres nacelles :

      # crictl rmp -fa

6. Arrêter manuellement les services crio :

   # systemctl stop crio

7. Après avoir exécuté ces commandes, vous pouvez effacer complètement le stockage éphémère :

   # crio wipe -f

8. Démarrer le service crio et kubelet :

   # systemctl start crio
   # systemctl start kubelet

9. Vous saurez que le nettoyage a fonctionné si les services crio et kubelet sont démarrés et si le nœud est dans l'état Ready:

   $ oc get nodes

   Exemple de sortie

   NAME				    STATUS	                ROLES    AGE    VERSION
   ci-ln-tkbxyft-f76d1-nvwhr-master-1  Ready, SchedulingDisabled   master	 133m   v1.25.0

10. Marquez le nœud comme étant planifiable. Vous saurez que l'ordonnancement est activé lorsque SchedulingDisabled n'aura plus d'état :

    oc adm uncordon <nodename> $ oc adm uncordon <nodename>

    Exemple de sortie

    NAME				     STATUS	      ROLES    AGE    VERSION
    ci-ln-tkbxyft-f76d1-nvwhr-master-1   Ready            master   133m   v1.25.0

Procédure

1. Exécutez la commande suivante pour afficher les unités de service qui ont échoué :

   $ systemctl --failed

2. Facultatif : Exécutez la commande suivante sur une unité de service individuelle pour obtenir plus d'informations :

   $ journalctl -u <unit>.service

Procédure

1. Liste des abonnements des opérateurs :

   $ oc get subs -n <operator_namespace>

2. Utilisez la commande oc describe pour inspecter une ressource Subscription:

   oc describe sub <subscription_name> -n <operator_namespace>

3. Dans la sortie de la commande, recherchez la section Conditions pour connaître l'état des types de conditions d'abonnement de l'opérateur. Dans l'exemple suivant, le type de condition CatalogSourcesUnhealthy a le statut false car toutes les sources de catalogue disponibles sont saines :

   Exemple de sortie

   Conditions:
      Last Transition Time:  2019-07-29T13:42:57Z
      Message:               all available catalogsources are healthy
      Reason:                AllCatalogSourcesHealthy
      Status:                False
      Type:                  CatalogSourcesUnhealthy

Procédure

1. Listez les sources de catalogue dans un espace de noms. Par exemple, vous pouvez vérifier l'espace de noms openshift-marketplace, qui est utilisé pour les sources de catalogue à l'échelle du cluster :

   $ oc get catalogsources -n openshift-marketplace

   Exemple de sortie

   NAME                  DISPLAY               TYPE   PUBLISHER   AGE
   certified-operators   Certified Operators   grpc   Red Hat     55m
   community-operators   Community Operators   grpc   Red Hat     55m
   example-catalog       Example Catalog       grpc   Example Org 2m25s
   redhat-marketplace    Red Hat Marketplace   grpc   Red Hat     55m
   redhat-operators      Red Hat Operators     grpc   Red Hat     55m

2. La commande oc describe permet d'obtenir plus de détails et de connaître l'état d'une source de catalogue :

   $ oc describe catalogsource example-catalog -n openshift-marketplace

   Exemple de sortie

   Name:         example-catalog
   Namespace:    openshift-marketplace
   ...
   Status:
     Connection State:
       Address:              example-catalog.openshift-marketplace.svc:50051
       Last Connect:         2021-09-09T17:07:35Z
       Last Observed State:  TRANSIENT_FAILURE
     Registry Service:
       Created At:         2021-09-09T17:05:45Z
       Port:               50051
       Protocol:           grpc
       Service Name:       example-catalog
       Service Namespace:  openshift-marketplace

   Dans l'exemple précédent, le dernier état observé est TRANSIENT_FAILURE. Cet état indique qu'il y a un problème pour établir une connexion pour la source du catalogue.

3. Listez les pods de l'espace de noms dans lequel votre source de catalogue a été créée :

   $ oc get pods -n openshift-marketplace

   Exemple de sortie

   NAME                                    READY   STATUS             RESTARTS   AGE
   certified-operators-cv9nn               1/1     Running            0          36m
   community-operators-6v8lp               1/1     Running            0          36m
   marketplace-operator-86bfc75f9b-jkgbc   1/1     Running            0          42m
   example-catalog-bwt8z                   0/1     ImagePullBackOff   0          3m55s
   redhat-marketplace-57p8c                1/1     Running            0          36m
   redhat-operators-smxx8                  1/1     Running            0          36m

   Lorsqu'une source de catalogue est créée dans un espace de noms, un pod pour la source de catalogue est créé dans cet espace de noms. Dans l'exemple de sortie précédent, le statut du pod example-catalog-bwt8z est ImagePullBackOff. Ce statut indique qu'il y a un problème lors de l'extraction de l'image d'index de la source de catalogue.

4. Utilisez la commande oc describe pour inspecter un pod et obtenir des informations plus détaillées :

   $ oc describe pod example-catalog-bwt8z -n openshift-marketplace

   Exemple de sortie

   Name:         example-catalog-bwt8z
   Namespace:    openshift-marketplace
   Priority:     0
   Node:         ci-ln-jyryyg2-f76d1-ggdbq-worker-b-vsxjd/10.0.128.2
   ...
   Events:
     Type     Reason          Age                From               Message
     ----     ------          ----               ----               -------
     Normal   Scheduled       48s                default-scheduler  Successfully assigned openshift-marketplace/example-catalog-bwt8z to ci-ln-jyryyf2-f76d1-fgdbq-worker-b-vsxjd
     Normal   AddedInterface  47s                multus             Add eth0 [10.131.0.40/23] from openshift-sdn
     Normal   BackOff         20s (x2 over 46s)  kubelet            Back-off pulling image "quay.io/example-org/example-catalog:v1"
     Warning  Failed          20s (x2 over 46s)  kubelet            Error: ImagePullBackOff
     Normal   Pulling         8s (x3 over 47s)   kubelet            Pulling image "quay.io/example-org/example-catalog:v1"
     Warning  Failed          8s (x3 over 47s)   kubelet            Failed to pull image "quay.io/example-org/example-catalog:v1": rpc error: code = Unknown desc = reading manifest v1 in quay.io/example-org/example-catalog: unauthorized: access to the requested resource is not authorized
     Warning  Failed          8s (x3 over 47s)   kubelet            Error: ErrImagePull

   Dans l'exemple précédent, les messages d'erreur indiquent que l'image d'index de la source de catalogue ne parvient pas à être extraite en raison d'un problème d'autorisation. Par exemple, l'image d'index peut être stockée dans un registre qui nécessite des identifiants de connexion.

Procédure

1. Liste des opérateurs en cours d'exécution dans la grappe. La sortie comprend la version de l'opérateur, la disponibilité et les informations sur le temps de fonctionnement :

   $ oc get clusteroperators

2. Liste des pods de l'opérateur en cours d'exécution dans l'espace de noms de l'opérateur, ainsi que l'état du pod, les redémarrages et l'âge :

   oc get pod -n <operator_namespace>

3. Produire un résumé détaillé de la nacelle de l'opérateur :

   oc describe pod <operator_pod_name> -n <operator_namespace>

4. Si un problème lié à l'opérateur est spécifique à un nœud, demander l'état du conteneur de l'opérateur sur ce nœud.

   1. Démarrer un pod de débogage pour le nœud :

      $ oc debug node/my-node

   2. Définissez /host comme répertoire racine dans le shell de débogage. Le pod de débogage monte le système de fichiers racine de l'hôte dans /host au sein du pod. En changeant le répertoire racine en /host, vous pouvez exécuter les binaires contenus dans les chemins d'exécution de l'hôte :

      # chroot /host

      Note

      Les nœuds de cluster OpenShift Container Platform 4.12 exécutant Red Hat Enterprise Linux CoreOS (RHCOS) sont immuables et s'appuient sur les opérateurs pour appliquer les changements de cluster. L'accès aux nœuds de cluster à l'aide de SSH n'est pas recommandé et les nœuds seront altérés en tant que accessed. Cependant, si l'API OpenShift Container Platform n'est pas disponible, ou si le kubelet ne fonctionne pas correctement sur le nœud cible, les opérations oc seront impactées. Dans de telles situations, il est possible d'accéder aux nœuds en utilisant ssh core@<node>.<cluster_name>.<base_domain> à la place.

   3. Liste les détails des conteneurs du nœud, y compris l'état et les ID de pods associés :

      # crictl ps

   4. Répertorie les informations relatives à un conteneur d'opérateur spécifique sur le nœud. L'exemple suivant répertorie les informations relatives au conteneur network-operator:

      # crictl ps --name network-operator

   5. Quitter le shell de débogage.

Procédure

1. Liste des pods de l'opérateur qui sont en cours d'exécution dans l'espace de noms de l'opérateur, ainsi que l'état du pod, les redémarrages et l'âge :

   oc get pods -n <operator_namespace>

2. Examiner les journaux d'un module d'opérateur :

   oc logs pod/<nom_du_pod> -n <espace_de_noms_de_l'opérateur>

   Si un module Opérateur a plusieurs conteneurs, la commande précédente produira une erreur qui inclura le nom de chaque conteneur. Interroger les journaux d'un conteneur individuel :

   oc logs pod/<operator_pod_name> -c <container_name> -n <operator_namespace> -c <container_name> -n <operator_namespace>

3. Si l'API n'est pas fonctionnelle, examinez les journaux des pods et des conteneurs de l'opérateur sur chaque nœud du plan de contrôle en utilisant plutôt SSH. Remplacez <master-node>.<cluster_name>.<base_domain> par les valeurs appropriées.

   1. Liste des pods sur chaque nœud du plan de contrôle :

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods

   2. Pour tout pod opérateur n'affichant pas l'état Ready, inspectez l'état du pod en détail. Remplacez <operator_pod_id> par l'ID du pod opérateur figurant dans la sortie de la commande précédente :

      ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <operator_pod_id>

   3. Liste des conteneurs liés à un module opérateur :

      ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps --pod=<operator_pod_id>

   4. Pour tout conteneur d'opérateur n'affichant pas l'état Ready, inspectez l'état du conteneur en détail. Remplacez <container_id> par un identifiant de conteneur figurant dans le résultat de la commande précédente :

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>

   5. Examinez les journaux des conteneurs de l'opérateur qui n'affichent pas l'état Ready. Remplacez <container_id> par un ID de conteneur figurant dans la sortie de la commande précédente :

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

      Note

      Les nœuds de cluster OpenShift Container Platform 4.12 exécutant Red Hat Enterprise Linux CoreOS (RHCOS) sont immuables et dépendent des opérateurs pour appliquer les changements de cluster. L'accès aux nœuds de cluster à l'aide de SSH n'est pas recommandé et les nœuds seront altérés comme accessed. Avant d'essayer de collecter des données de diagnostic via SSH, vérifiez si les données collectées en exécutant oc adm must gather et d'autres commandes oc sont suffisantes. Cependant, si l'API OpenShift Container Platform n'est pas disponible, ou si le kubelet ne fonctionne pas correctement sur le nœud cible, les opérations oc seront impactées. Dans de telles situations, il est possible d'accéder aux nœuds en utilisant ssh core@<node>.<cluster_name>.<base_domain>.

Procédure

1. Obtenir les noms des objets Subscription et ClusterServiceVersion de l'espace de noms dans lequel l'opérateur est installé :

   $ oc get sub,csv -n <namespace>

   Exemple de sortie

   NAME                                                       PACKAGE                  SOURCE             CHANNEL
   subscription.operators.coreos.com/elasticsearch-operator   elasticsearch-operator   redhat-operators   5.0
   
   NAME                                                                         DISPLAY                            VERSION    REPLACES   PHASE
   clusterserviceversion.operators.coreos.com/elasticsearch-operator.5.0.0-65   OpenShift Elasticsearch Operator   5.0.0-65              Succeeded

2. Supprimer l'abonnement :

   oc delete subscription <subscription_name> -n <namespace> $ oc delete subscription <subscription_name> -n <namespace>

3. Supprimer la version du service de cluster :

   $ oc delete csv <csv_name> -n <namespace>

4. Récupère les noms de tous les travaux défaillants et des cartes de configuration correspondantes dans l'espace de noms openshift-marketplace:

   $ oc get job,configmap -n openshift-marketplace

   Exemple de sortie

   NAME                                                                        COMPLETIONS   DURATION   AGE
   job.batch/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   1/1           26s        9m30s
   
   NAME                                                                        DATA   AGE
   configmap/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   3      9m30s

5. Supprimer le travail :

   oc delete job <job_name> -n openshift-marketplace

   Cela permet de s'assurer que les pods qui tentent d'extraire l'image inaccessible ne sont pas recréés.

6. Supprimer la carte de configuration :

   oc delete configmap <configmap_name> -n openshift-marketplace

7. Réinstallez l'opérateur en utilisant OperatorHub dans la console web.

Procédure

1. Passer à un projet :

   oc project <nom_du_projet>

2. Liste des pods en cours d'exécution dans l'espace de noms, ainsi que l'état des pods, les états d'erreur, les redémarrages et l'âge :

   $ oc get pods

3. Déterminez si l'espace de noms est géré par une configuration de déploiement :

   $ oc status

   Si l'espace de noms est géré par une configuration de déploiement, le résultat comprend le nom de la configuration de déploiement et une référence à l'image de base.

4. Inspecter l'image de base référencée dans la sortie de la commande précédente :

   skopeo inspect docker://<image_reference>

5. Si la référence de l'image de base n'est pas correcte, mettez à jour la référence dans la configuration du déploiement :

   $ oc edit deployment/my-deployment

6. Lorsque la configuration du déploiement change à la sortie, la configuration sera automatiquement redéployée. Surveillez l'état du pod au fur et à mesure que le déploiement progresse, afin de déterminer si le problème a été résolu :

   $ oc get pods -w

7. Examinez les événements de l'espace de noms pour y trouver des informations de diagnostic relatives aux défaillances des pods :

   $ oc get events

Procédure

1. Interroger les journaux pour un module spécifique :

   oc logs <nom_du_pod>

2. Interroger les journaux d'un conteneur spécifique au sein d'un pod :

   oc logs <nom_du_pod> -c <nom_du_conteneur>

   Les journaux récupérés à l'aide des commandes oc logs précédentes sont composés de messages envoyés à stdout à l'intérieur des pods ou des conteneurs.

3. Inspecter les grumes contenues dans /var/log/ à l'intérieur d'une nacelle.

   1. Liste des fichiers journaux et des sous-répertoires contenus dans /var/log au sein d'un pod :

      oc exec <nom_du_pod> ls -alh /var/log

   2. Interroger un fichier journal spécifique contenu dans /var/log au sein d'un pod :

      oc exec <nom_du_pod> cat /var/log/<chemin_vers_log>

   3. Liste des fichiers journaux et des sous-répertoires contenus dans /var/log à l'intérieur d'un conteneur spécifique :

      oc exec <nom_du_pod> -c <nom_du_conteneur> ls /var/log

   4. Interroger un fichier journal spécifique contenu dans /var/log à l'intérieur d'un conteneur spécifique :

      oc exec <nom_du_pod> -c <nom_du_conteneur> cat /var/log/<chemin_vers_log>

Procédure

1. Entrez dans le projet qui contient le pod auquel vous souhaitez accéder. Cette opération est nécessaire car la commande oc rsh n'accepte pas l'option d'espace de noms -n:

   oc project <namespace>

2. Démarrer un shell à distance dans un pod :

   $ oc rsh <pod_name>  1

   1

   Si un module a plusieurs conteneurs, oc rsh prend par défaut le premier conteneur, à moins que -c <container_name> ne soit spécifié.

3. Lancer un shell à distance dans un conteneur spécifique au sein d'un pod :

   oc rsh -c <container_name> pod/<pod_name>

4. Créer une session de transfert de port vers un port d'un pod :

   $ oc port-forward <pod_name> <host_port>:<pod_port>  1

   1

   Saisissez Ctrl C pour annuler la session de transfert de port.

Procédure

1. Démarrer un pod de débogage avec un accès root, sur la base d'un déploiement.

   1. Obtenir le nom de déploiement d'un projet :

      oc get deployment -n <nom_du_projet>

   2. Démarrer un pod de débogage avec les privilèges root, en fonction du déploiement :

      $ oc debug deployment/my-deployment --as-root -n <nom_du_projet>

2. Démarrer un pod de débogage avec un accès root, sur la base d'une configuration de déploiement.

   1. Obtenir le nom de la configuration de déploiement d'un projet :

      oc get deploymentconfigs -n <nom_du_projet>

   2. Démarrer un pod de débogage avec les privilèges de root, en fonction de la configuration du déploiement :

      $ oc debug deploymentconfig/my-deployment-configuration --as-root -n <nom_du_projet>

Procédure

1. Copier un fichier dans un pod :

   $ oc cp <local_path> <pod_name>:/<path> -c <container_name>  1

   1

   Le premier conteneur d'un pod est sélectionné si l'option -c n'est pas spécifiée.

2. Copier un fichier à partir d'un pod :

   $ oc cp <pod_name>:/<path>  -c <container_name><local_path>  1

   1

   Le premier conteneur d'un pod est sélectionné si l'option -c n'est pas spécifiée.

   Note

   Pour que oc cp fonctionne, le binaire tar doit être disponible dans le conteneur.

1. During the build configuration stageun pod de construction est utilisé pour créer une image de conteneur d'application à partir d'une image de base et du code source de l'application.
2. During the deployment configuration stageun pod de déploiement est utilisé pour déployer des pods d'application à partir de l'image du conteneur d'application qui a été construite lors de l'étape de configuration de la construction. Le module de déploiement déploie également d'autres ressources telles que des services et des itinéraires. La configuration du déploiement commence après la réussite de la configuration de la construction.
3. After the deployment pod has started the application podsles pannes d'application peuvent se produire dans les modules d'application en cours d'exécution. Par exemple, une application peut ne pas se comporter comme prévu bien que les modules d'application soient dans l'état Running. Dans ce cas, vous pouvez accéder aux modules d'application en cours d'exécution afin d'examiner les défaillances d'une application au sein d'un module.

1. Contrôler l'état de la construction, du déploiement et du pod d'application
2. Déterminer l'étape du processus S2I où le problème s'est produit
3. Examiner les journaux correspondant à l'étape échouée

Procédure

1. Surveillez l'état du pod tout au long du processus S2I afin de déterminer à quel stade une défaillance se produit :

   $ oc get pods -w  1

   1

   Utilisez -w pour surveiller les modifications apportées aux pods jusqu'à ce que vous quittiez la commande à l'aide de Ctrl C.

2. Examinez les journaux d'un pod qui a échoué pour y déceler les erreurs.

   • If the build pod fails, examinez les journaux du module de construction :

     oc logs -f pod/<application_name>-<build_number>-build

     Note

     Vous pouvez également consulter les journaux de la configuration de construction en utilisant oc logs -f bc/<application_name>. Les journaux de la configuration de construction comprennent les journaux du module de construction.

   • If the deployment pod failsle cas échéant, examinez les journaux du module de déploiement :

     $ oc logs -f pod/<application_name>-<build_number>-deploy

     Note

     Vous pouvez également consulter les journaux de la configuration de déploiement à l'aide de oc logs -f dc/<application_name>. Cette commande génère des journaux à partir du module de déploiement jusqu'à ce que ce dernier se termine avec succès. La commande affiche les journaux des modules d'application si vous l'exécutez après la fin du module de déploiement. Après la fin d'un module de déploiement, il est toujours possible d'accéder à ses journaux en exécutant la commande oc logs -f pod/<application_name>-<build_number>-deploy.

   • If an application pod fails, or if an application is not behaving as expected within a running application podpour ce faire, consultez les journaux du module d'application :

     $ oc logs -f pod/<application_name>-<build_number>-<random_string>

Procédure

1. Répertorie les événements relatifs à un module d'application spécifique. L'exemple suivant permet de récupérer les événements d'un module d'application nommé my-app-1-akdlg:

   $ oc describe pod/my-app-1-akdlg

2. Examiner les journaux d'un module d'application :

   $ oc logs -f pod/my-app-1-akdlg

3. Interroger des logs spécifiques dans un pod d'application en cours d'exécution. Les logs qui sont envoyés à stdout sont collectés par le framework OpenShift Logging et sont inclus dans la sortie de la commande précédente. La requête suivante n'est nécessaire que pour les journaux qui ne sont pas envoyés à stdout.

   1. S'il est possible d'accéder à un journal d'application sans les privilèges de l'administrateur dans un module, concaténer le fichier journal comme suit :

      $ oc exec my-app-1-akdlg -- cat /var/log/my-application.log

   2. Si l'accès root est nécessaire pour consulter le journal d'une application, vous pouvez démarrer un conteneur de débogage avec les privilèges root, puis consulter le fichier journal à partir du conteneur. Démarrez le conteneur de débogage à partir de l'objet DeploymentConfig du projet. Les utilisateurs de pods s'exécutent généralement avec des privilèges non root, mais l'exécution de pods de dépannage avec des privilèges root temporaires peut s'avérer utile lors de l'investigation d'un problème :

      $ oc debug dc/my-deployment-configuration --as-root -- cat /var/log/my-application.log

      Note

      Vous pouvez accéder à un shell interactif avec un accès root dans le pod de débogage si vous exécutez oc debug dc/<deployment_configuration> --as-root sans ajouter -- <command>.

4. Tester les fonctionnalités d'une application de manière interactive et exécuter des outils de diagnostic, dans un conteneur d'application avec un shell interactif.

   1. Démarrer un shell interactif sur le conteneur d'application :

      $ oc exec -it my-app-1-akdlg /bin/bash

   2. Tester les fonctionnalités de l'application de manière interactive à partir de l'interpréteur de commandes. Par exemple, vous pouvez exécuter la commande du point d'entrée du conteneur et observer les résultats. Ensuite, vous pouvez tester les modifications directement à partir de la ligne de commande, avant de mettre à jour le code source et de reconstruire le conteneur d'application par le biais du processus S2I.

   3. Exécuter les binaires de diagnostic disponibles dans le conteneur.

      Note

      Les privilèges root sont nécessaires pour exécuter certains binaires de diagnostic. Dans ce cas, vous pouvez démarrer un pod de débogage avec un accès root, basé sur l'objet DeploymentConfig d'un pod problématique, en exécutant oc debug dc/<deployment_configuration> --as-root. Ensuite, vous pouvez exécuter les binaires de diagnostic en tant que root à partir du pod de débogage.

5. Si les binaires de diagnostic ne sont pas disponibles dans un conteneur, vous pouvez exécuter les binaires de diagnostic d'un hôte dans l'espace de noms d'un conteneur en utilisant nsenter. L'exemple suivant exécute ip ad dans l'espace de noms d'un conteneur, en utilisant le binaire ip de l'hôte.

   1. Entrez dans une session de débogage sur le nœud cible. Cette étape instancie un pod de débogage appelé <node_name>-debug:

      $ oc debug node/my-cluster-node

   2. Définissez /host comme répertoire racine dans le shell de débogage. Le pod de débogage monte le système de fichiers racine de l'hôte dans /host au sein du pod. En changeant le répertoire racine en /host, vous pouvez exécuter les binaires contenus dans les chemins d'exécution de l'hôte :

      # chroot /host

      Note

      Les nœuds de cluster OpenShift Container Platform 4.12 exécutant Red Hat Enterprise Linux CoreOS (RHCOS) sont immuables et s'appuient sur les opérateurs pour appliquer les changements de cluster. L'accès aux nœuds de cluster à l'aide de SSH n'est pas recommandé et les nœuds seront altérés en tant que accessed. Cependant, si l'API OpenShift Container Platform n'est pas disponible, ou si le kubelet ne fonctionne pas correctement sur le nœud cible, les opérations oc seront impactées. Dans de telles situations, il est possible d'accéder aux nœuds en utilisant ssh core@<node>.<cluster_name>.<base_domain> à la place.

   3. Déterminer l'ID du conteneur cible :

      # crictl ps

   4. Déterminer l'ID du processus du conteneur. Dans cet exemple, l'ID du conteneur cible est a7fe32346b120:

      # crictl inspect a7fe32346b120 --output yaml | grep 'pid:' | awk '{print $2}'

   5. Exécutez ip ad dans l'espace de noms du conteneur, en utilisant le binaire ip de l'hôte. Cet exemple utilise 31150 comme ID de processus du conteneur. La commande nsenter entre dans l'espace de noms d'un processus cible et exécute une commande dans son espace de noms. Comme le processus cible dans cet exemple est l'ID de processus d'un conteneur, la commande ip ad est exécutée dans l'espace de noms du conteneur à partir de l'hôte :

      # nsenter -n -t 31150 -- ip ad

      Note

      L'exécution des binaires de diagnostic d'un hôte dans l'espace de noms d'un conteneur n'est possible que si vous utilisez un conteneur privilégié tel qu'un nœud de débogage.

Procédure

1. Pour afficher les journaux dans tous les répertoires de C:\var\logs, exécutez la commande suivante :

   $ oc adm node-logs -l kubernetes.io/os=windows --path= \
       /ip-10-0-138-252.us-east-2.compute.internal containers \
       /ip-10-0-138-252.us-east-2.compute.internal hybrid-overlay \
       /ip-10-0-138-252.us-east-2.compute.internal kube-proxy \
       /ip-10-0-138-252.us-east-2.compute.internal kubelet \
       /ip-10-0-138-252.us-east-2.compute.internal pods

2. Vous pouvez désormais lister les fichiers dans les répertoires à l'aide de la même commande et afficher les fichiers journaux individuels. Par exemple, pour afficher les journaux des kubelets, exécutez la commande suivante :

   $ oc adm node-logs -l kubernetes.io/os=windows --path=/kubelet/kubelet.log

Procédure

1. Accédez au nœud Windows par SSH et entrez dans PowerShell :

   C:\N> powershell

2. Affichez les journaux Docker en exécutant la commande suivante :

   C:\N> Get-EventLog -LogName Application -Source Docker

Procédure

1. Check that the corresponding labels match dans les configurations des services et des ressources ServiceMonitor.

   1. Obtenir le label défini dans le service. L'exemple suivant interroge le service prometheus-example-app dans le projet ns1:

      $ oc -n ns1 get service prometheus-example-app -o yaml

      Exemple de sortie

        labels:
          app: prometheus-example-app

   2. Vérifiez que l'étiquette matchLabels app dans la configuration de la ressource ServiceMonitor correspond à l'étiquette produite à l'étape précédente :

      $ oc -n ns1 get servicemonitor prometheus-example-monitor -o yaml

      Exemple de sortie

      spec:
        endpoints:
        - interval: 30s
          port: web
          scheme: http
        selector:
          matchLabels:
            app: prometheus-example-app

      Note

      Vous pouvez vérifier les étiquettes de service et de ressource ServiceMonitor en tant que développeur disposant d'autorisations de visualisation pour le projet.

2. Inspect the logs for the Prometheus Operator dans le projet openshift-user-workload-monitoring.

   1. Liste les pods du projet openshift-user-workload-monitoring:

      $ oc -n openshift-user-workload-monitoring get pods

      Exemple de sortie

      NAME                                   READY   STATUS    RESTARTS   AGE
      prometheus-operator-776fcbbd56-2nbfm   2/2     Running   0          132m
      prometheus-user-workload-0             5/5     Running   1          132m
      prometheus-user-workload-1             5/5     Running   1          132m
      thanos-ruler-user-workload-0           3/3     Running   0          132m
      thanos-ruler-user-workload-1           3/3     Running   0          132m

   2. Obtenez les journaux du conteneur prometheus-operator dans le pod prometheus-operator. Dans l'exemple suivant, le module s'appelle prometheus-operator-776fcbbd56-2nbfm:

      $ oc -n openshift-user-workload-monitoring logs prometheus-operator-776fcbbd56-2nbfm -c prometheus-operator

      En cas de problème avec le moniteur de service, les journaux peuvent contenir une erreur similaire à cet exemple :

      level=warn ts=2020-08-10T11:48:20.906739623Z caller=operator.go:1829 component=prometheusoperator msg="skipping servicemonitor" error="it accesses file system via bearer token file which Prometheus specification prohibits" servicemonitor=eagle/eagle namespace=openshift-user-workload-monitoring prometheus=user-workload

3. Review the target status for your endpoint sur la page Metrics targets dans l'interface de la console web de OpenShift Container Platform.

   1. Connectez-vous à la console web de OpenShift Container Platform et naviguez vers Observe → Targets dans la perspective Administrator.
   2. Localisez le point de terminaison des métriques dans la liste et vérifiez l'état de la cible dans la colonne Status.
   3. Si l'adresse Status est Down, cliquez sur l'URL du point de terminaison pour obtenir plus d'informations sur la page Target Details relative à cette cible de mesure.

4. Configure debug level logging for the Prometheus Operator dans le projet openshift-user-workload-monitoring.

   1. Modifiez l'objet user-workload-monitoring-config ConfigMap dans le projet openshift-user-workload-monitoring:

      $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

   2. Ajoutez logLevel: debug pour prometheusOperator sous data/config.yaml pour définir le niveau du journal à debug:

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          prometheusOperator:
            logLevel: debug

   3. Enregistrez le fichier pour appliquer les modifications.

      Note

      Le site prometheus-operator du projet openshift-user-workload-monitoring redémarre automatiquement lorsque vous appliquez la modification du niveau de journalisation.

   4. Confirmez que le niveau de journalisation debug a été appliqué au déploiement prometheus-operator dans le projet openshift-user-workload-monitoring:

      $ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml |  grep "log-level"

      Exemple de sortie

              - --log-level=debug

      La journalisation de niveau débogage montre tous les appels effectués par l'opérateur Prometheus.

   5. Vérifiez que le pod prometheus-operator fonctionne :

      $ oc -n openshift-user-workload-monitoring get pods

      Note

      Si une valeur Prometheus Operator loglevel non reconnue est incluse dans la carte de configuration, le pod prometheus-operator peut ne pas redémarrer avec succès.

   6. Examinez les journaux de débogage pour voir si l'opérateur Prometheus utilise la ressource ServiceMonitor. Examinez les journaux pour voir s'il y a d'autres erreurs connexes.

Procédure

1. Dans la perspective Administrator, naviguez vers Observe → Metrics.

2. Exécutez la requête Prometheus Query Language (PromQL) suivante dans le champ Expression. Cette requête renvoie les dix métriques qui ont le plus grand nombre d'échantillons de scrape :

   topk(10,count by (job)({__name__=~".+"}))

3. Étudier le nombre de valeurs d'étiquettes non liées attribuées à des mesures dont le nombre d'échantillons raclés est plus élevé que prévu.

   • If the metrics relate to a user-defined projectdans le cas d'une charge de travail, passez en revue les paires clé-valeur de métriques attribuées à votre charge de travail. Celles-ci sont mises en œuvre par les bibliothèques client Prometheus au niveau de l'application. Essayez de limiter le nombre d'attributs non liés référencés dans vos étiquettes.
   • If the metrics relate to a core OpenShift Container Platform projectcréez un dossier d'assistance Red Hat sur le portail client Red Hat.

4. Examinez l'état de la TSDB à l'aide de l'API HTTP Prometheus en exécutant les commandes suivantes en tant qu'administrateur de cluster :

   $ oc login -u <nom d'utilisateur> -p <mot de passe>

   $ host=$(oc -n openshift-monitoring get route prometheus-k8s -ojsonpath={.spec.host})

   $ token=$(oc whoami -t)

   $ curl -H "Authorization: Bearer $token" -k "https://$host/api/v1/status/tsdb"

   Exemple de sortie

   "status": "success",

Procédure

1. Spécifier le niveau de journalisation de oc lors de l'exécution d'une commande oc:

   oc <options> --loglevel <log_level>

2. Le jeton de session actuel de l'utilisateur d'OpenShift Container Platform est généralement inclus dans les demandes enregistrées sur curl, le cas échéant. Vous pouvez également obtenir manuellement le jeton de session de l'utilisateur actuel, pour tester étape par étape certains aspects du processus sous-jacent d'une commande oc:

   $ oc whoami -t