21.5. Installation manuelle d'un cluster OpenShift à un nœud avec ZTP

Procédure

1. Créez un dossier de sortie en exécutant la commande suivante :

   $ mkdir -p ./out

2. Exporter le répertoire argocd à partir de l'image du conteneur ztp-site-generate:

   $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12 extract /home/ztp --tar | tar x -C ./out

   Le répertoire ./out contient les CR de référence PolicyGenTemplate et SiteConfig dans le dossier out/argocd/example/.

   Exemple de sortie

   out
    └── argocd
         └── example
              ├── policygentemplates
              │     ├── common-ranGen.yaml
              │     ├── example-sno-site.yaml
              │     ├── group-du-sno-ranGen.yaml
              │     ├── group-du-sno-validator-ranGen.yaml
              │     ├── kustomization.yaml
              │     └── ns.yaml
              └── siteconfig
                     ├── example-sno.yaml
                     ├── KlusterletAddonConfigOverride.yaml
                     └── kustomization.yaml

3. Créez un dossier de sortie pour les CR d'installation du site :

   $ mkdir -p ./site-install

4. Modifiez l'exemple de CR SiteConfig pour le type de cluster que vous voulez installer. Copiez example-sno.yaml vers site-1-sno.yaml et modifiez le CR pour qu'il corresponde aux détails du site et de l'hôte bare-metal que vous souhaitez installer, par exemple :

   Exemple de cluster OpenShift à nœud unique SiteConfig CR

   apiVersion: ran.openshift.io/v1
   kind: SiteConfig
   metadata:
     name: "<site_name>"
     namespace: "<site_name>"
   spec:
     baseDomain: "example.com"
     pullSecretRef:
       name: "assisted-deployment-pull-secret" 1
     clusterImageSetNameRef: "openshift-4.12" 2
     sshPublicKey: "ssh-rsa AAAA..." 3
     clusters:
     - clusterName: "<site_name>"
       networkType: "OVNKubernetes"
       clusterLabels: 4
         common: true
         group-du-sno: ""
         sites : "<site_name>"
       clusterNetwork:
         - cidr: 1001:1::/48
           hostPrefix: 64
       machineNetwork:
         - cidr: 1111:2222:3333:4444::/64
       serviceNetwork:
         - 1001:2::/112
       additionalNTPSources:
         - 1111:2222:3333:4444::2
       #crTemplates:
       #  KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml" 5
       nodes:
         - hostName: "example-node.example.com" 6
           role: "master"
           bmcAddress: idrac-virtualmedia://<out_of_band_ip>/<system_id>/ 7
           bmcCredentialsName:
             name: "bmh-secret" 8
           bootMACAddress: "AA:BB:CC:DD:EE:11"
           bootMode: "UEFI" 9
           rootDeviceHints:
             wwn: "0x11111000000asd123"
           cpuset: "0-1,52-53"  10
           nodeNetwork: 11
             interfaces:
               - name: eno1
                 macAddress: "AA:BB:CC:DD:EE:11"
             config:
               interfaces:
                 - name: eno1
                   type: ethernet
                   state: up
                   ipv4:
                     enabled: false
                   ipv6: 12
                     enabled: true
                     address:
                     - ip: 1111:2222:3333:4444::aaaa:1
                       prefix-length: 64
               dns-resolver:
                 config:
                   search:
                   - example.com
                   server:
                   - 1111:2222:3333:4444::2
               routes:
                 config:
                 - destination: ::/0
                   next-hop-interface: eno1
                   next-hop-address: 1111:2222:3333:4444::1
                   table-id: 254

   1

   Créez le CR assisted-deployment-pull-secret avec le même espace de noms que le CR SiteConfig.

   2

   clusterImageSetNameRef définit un jeu d'images disponible sur le hub cluster. Pour voir la liste des versions supportées sur votre hub cluster, exécutez oc get clusterimagesets.

   3

   Configurer la clé publique SSH utilisée pour accéder au cluster.

   4

   Les libellés des grappes doivent correspondre au champ bindingRules dans les CR PolicyGenTemplate que vous définissez. Par exemple, policygentemplates/common-ranGen.yaml s'applique à tous les clusters dont le champ common: true est défini, policygentemplates/group-du-sno-ranGen.yaml s'applique à tous les clusters dont le champ group-du-sno: "" est défini.

   5

   Facultatif. Le CR spécifié sous KlusterletAddonConfig est utilisé pour remplacer le CR par défaut KlusterletAddonConfig qui est créé pour le cluster.

   6

   Pour les déploiements à un seul nœud, définissez un seul hôte. Pour les déploiements à trois nœuds, définissez trois hôtes. Pour les déploiements standard, définissez trois hôtes avec role: master et deux hôtes ou plus avec role: worker.

   7

   Adresse BMC que vous utilisez pour accéder à l'hôte. S'applique à tous les types de clusters.

   8

   Nom du CR bmh-secret que vous créez séparément avec les informations d'identification BMC de l'hôte. Lorsque vous créez le CR bmh-secret, utilisez le même espace de noms que le CR SiteConfig qui approvisionne l'hôte.

   9

   Configure le mode de démarrage de l'hôte. La valeur par défaut est UEFI. Utilisez UEFISecureBoot pour activer le démarrage sécurisé sur l'hôte.

   10

   cpuset doit correspondre à la valeur définie dans le champ cluster PerformanceProfile CR spec.cpu.reserved pour le partitionnement de la charge de travail.

   11

   Spécifie les paramètres du réseau pour le nœud.

   12

   Configure l'adresse IPv6 pour l'hôte. Pour les clusters OpenShift à un seul nœud avec des adresses IP statiques, l'API spécifique au nœud et les IP d'entrée doivent être les mêmes.

5. Générer les CR d'installation du jour 0 en traitant le CR SiteConfig modifié site-1-sno.yaml en exécutant la commande suivante :

   $ podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-install:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12.1 generator install site-1-sno.yaml /output

   Exemple de sortie

   site-install
   └── site-1-sno
       ├── site-1_agentclusterinstall_example-sno.yaml
       ├── site-1-sno_baremetalhost_example-node1.example.com.yaml
       ├── site-1-sno_clusterdeployment_example-sno.yaml
       ├── site-1-sno_configmap_example-sno.yaml
       ├── site-1-sno_infraenv_example-sno.yaml
       ├── site-1-sno_klusterletaddonconfig_example-sno.yaml
       ├── site-1-sno_machineconfig_02-master-workload-partitioning.yaml
       ├── site-1-sno_machineconfig_predefined-extra-manifests-master.yaml
       ├── site-1-sno_machineconfig_predefined-extra-manifests-worker.yaml
       ├── site-1-sno_managedcluster_example-sno.yaml
       ├── site-1-sno_namespace_example-sno.yaml
       └── site-1-sno_nmstateconfig_example-node1.example.com.yaml

6. Facultatif : Générer uniquement les CR d'installation du jour 0 MachineConfig pour un type de cluster particulier en traitant le CR de référence SiteConfig avec l'option -E. Par exemple, exécutez les commandes suivantes :

   1. Créer un dossier de sortie pour les CR MachineConfig:

      $ mkdir -p ./site-machineconfig

   2. Générer les CR d'installation de MachineConfig:

      $ podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-machineconfig:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12.1 generator install -E site-1-sno.yaml /output

      Exemple de sortie

      site-machineconfig
      └── site-1-sno
          ├── site-1-sno_machineconfig_02-master-workload-partitioning.yaml
          ├── site-1-sno_machineconfig_predefined-extra-manifests-master.yaml
          └── site-1-sno_machineconfig_predefined-extra-manifests-worker.yaml

7. Générez et exportez les CR de configuration du jour 2 en utilisant les CR de référence PolicyGenTemplate de l'étape précédente. Exécutez les commandes suivantes :

   1. Créer un dossier de sortie pour les CR du jour 2 :

      $ mkdir -p ./ref

   2. Générer et exporter les CR de configuration du jour 2 :

      $ podman run -it --rm -v `pwd`/out/argocd/example/policygentemplates:/resources:Z -v `pwd`/ref:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12.1 generator config -N . /output

      La commande génère des exemples de CR de groupe et de site PolicyGenTemplate pour OpenShift à un nœud, des clusters à trois nœuds et des clusters standard dans le dossier ./ref.

      Exemple de sortie

      ref
       └── customResource
            ├── common
            ├── example-multinode-site
            ├── example-sno
            ├── group-du-3node
            ├── group-du-3node-validator
            │    └── Multiple-validatorCRs
            ├── group-du-sno
            ├── group-du-sno-validator
            ├── group-du-standard
            └── group-du-standard-validator
                 └── Multiple-validatorCRs

8. Utilisez les CR générés comme base pour les CR que vous utilisez pour installer le cluster. Vous appliquez les CR d'installation au cluster concentrateur comme décrit dans la section "Installation d'un cluster géré unique". Les CR de configuration peuvent être appliqués à la grappe une fois l'installation de la grappe terminée.

Procédure

1. Créer un fichier secret YAML contenant les informations d'identification pour le contrôleur de gestion de carte de base (BMC) de l'hôte et un secret d'extraction requis pour l'installation d'OpenShift et de tous les opérateurs de cluster supplémentaires :

   1. Enregistrer le YAML suivant dans le fichier example-sno-secret.yaml:

      apiVersion: v1
      kind: Secret
      metadata:
        name: example-sno-bmc-secret
        namespace: example-sno 1
      data: 2
        password: <base64_password>
        username: <base64_username>
      type: Opaque
      ---
      apiVersion: v1
      kind: Secret
      metadata:
        name: pull-secret
        namespace: example-sno  3
      data:
        .dockerconfigjson: <pull_secret> 4
      type: kubernetes.io/dockerconfigjson

      1

      Doit correspondre à l'espace de noms configuré dans la CR SiteConfig correspondante

      2

      Valeurs encodées en base64 pour password et username

      3

      Doit correspondre à l'espace de noms configuré dans la CR SiteConfig correspondante

      4

      Secret d'extraction codé en base64

2. Ajoutez le chemin relatif vers example-sno-secret.yaml au fichier kustomization.yaml que vous utilisez pour installer le cluster.

Procédure

1. Modifiez la spécification spec.kernelArguments dans le CR InfraEnv pour configurer les arguments du noyau :

1. Ouvrez une session SSH avec l'hôte cible :

   $ ssh -i /path/to/privatekey core@<nom_de_l'hôte>

2. Affichez les arguments du noyau du système à l'aide de la commande suivante :

   $ cat /proc/cmdline

Procédure

1. Créez un ClusterImageSet pour chaque version spécifique du cluster à déployer, par exemple clusterImageSet-4.12.yaml. Un ClusterImageSet a le format suivant :

   apiVersion: hive.openshift.io/v1
   kind: ClusterImageSet
   metadata:
     name: openshift-4.12.0 1
   spec:
      releaseImage: quay.io/openshift-release-dev/ocp-release:4.12.0-x86_64 2

   1

   La version descriptive que vous souhaitez déployer.

   2

   Spécifie le site releaseImage à déployer et détermine la version de l'image du système d'exploitation. L'ISO de découverte est basée sur la version de l'image définie par releaseImage, ou sur la dernière version si la version exacte n'est pas disponible.

2. Appliquer la CR clusterImageSet:

   $ oc apply -f clusterImageSet-4.12.yaml

3. Créer le CR Namespace dans le fichier cluster-namespace.yaml:

   apiVersion: v1
   kind: Namespace
   metadata:
        name: <cluster_name> 1
        labels:
           name: <cluster_name> 2

   1 2

   Le nom du cluster géré à provisionner.

4. Appliquez la CR Namespace en exécutant la commande suivante :

   $ oc apply -f cluster-namespace.yaml

5. Appliquez les CR du jour 0 que vous avez extraites du conteneur ztp-site-generate et que vous avez personnalisées pour répondre à vos besoins :

   $ oc apply -R ./site-install/site-sno-1

Procédure

1. Vérifiez l'état du cluster géré :

   $ oc get managedcluster

   True indique que le cluster géré est prêt.

2. Vérifier le statut de l'agent :

   oc get agent -n <cluster_name>

3. Utilisez la commande describe pour obtenir une description détaillée de l'état de l'agent. Les statuts à connaître sont BackendError, InputError, ValidationsFailing, InstallationFailed et AgentIsConnected. Ces statuts concernent les ressources personnalisées Agent et AgentClusterInstall.

   oc describe agent -n <cluster_name>

4. Vérifier l'état de l'approvisionnement du cluster :

   oc get agentclusterinstall -n <cluster_name>

5. Utilisez la commande describe pour obtenir une description détaillée de l'état de l'approvisionnement de la grappe :

   oc describe agentclusterinstall -n <cluster_name>

6. Vérifiez l'état des services complémentaires du cluster géré :

   oc get managedclusteraddon -n <cluster_name>

7. Récupérer les informations d'authentification du fichier kubeconfig pour le cluster géré :

   $ oc get secret -n <cluster_name> <cluster_name>-admin-kubeconfig -o jsonpath={.data.kubeconfig} | base64 -d > <directory>/<cluster_name>-kubeconfig

Procédure

1. Vérifiez l'état du cluster géré :

   $ oc get managedcluster

   Exemple de sortie

   NAME            HUB ACCEPTED   MANAGED CLUSTER URLS   JOINED   AVAILABLE   AGE
   SNO-cluster     true                                   True     True      2d19h

   Si le statut dans la colonne AVAILABLE est True, le cluster géré est géré par le hub.

   Si le statut dans la colonne AVAILABLE est Unknown, le cluster géré n'est pas géré par le concentrateur. Suivez les étapes suivantes pour continuer la vérification et obtenir plus d'informations.

2. Vérifiez l'état de l'installation de AgentClusterInstall:

   oc get clusterdeployment -n <cluster_name>

   Exemple de sortie

   NAME        PLATFORM            REGION   CLUSTERTYPE   INSTALLED    INFRAID    VERSION  POWERSTATE AGE
   Sno0026    agent-baremetal                               false                          Initialized
   2d14h

   Si l'état de la colonne INSTALLED est false, l'installation a échoué.

3. Si l'installation a échoué, entrez la commande suivante pour vérifier l'état de la ressource AgentClusterInstall:

   oc describe agentclusterinstall -n <cluster_name> <cluster_name> $ oc describe agentclusterinstall -n <cluster_name>

4. Résolvez les erreurs et réinitialisez le cluster :

   1. Supprimer la ressource cluster gérée du cluster :

      oc delete managedcluster <cluster_name> $ oc delete managedcluster <cluster_name>

   2. Supprimer l'espace de noms du cluster :

      oc delete namespace <cluster_name> $ oc delete namespace <cluster_name>

      Cette opération supprime toutes les ressources personnalisées de l'espace de nommage créées pour ce cluster. Vous devez attendre que la suppression de ManagedCluster CR soit terminée avant de poursuivre.

   3. Recréer les ressources personnalisées pour le cluster géré.