Retour aux articles

Home >> Blog >> Comment déployer un cluster Openshift dans AWS

DevOps
Cloud

Comment déployer un cluster Openshift dans AWS

21 novembre 2022

By Lionel Gurret.

Contexte

Grâce à la plateforme Openshift (OCP), des milliers d’entreprises permettent à leurs développeurs de construire, déployer, et exécuter des applications dans des conteneurs.

Cette plateforme propose en outre des fonctionnalités poussées comme :

  • Une gestion utilisateur, de droits et d’authentification
  • Une interface utilisateur
  • Des outils de CI et de CD
  • L’intégration d’un registre privé
  • Du monitoring et du logging

Cette plateforme peut être hébergée aussi bien sur un cloud privé (on-premise) que sur un cloud public.

Il est possible d’installer Openshift de deux façons différentes :

  • IPI (Installer provisioned infrastructure cluster) : l’installation sera automatisée de bout en bout. Par exemple, les ressources composants l’infrastructure comme les enregistrements DNS ou les serveurs seront provisionnés automatiquement par l’installeur dans le cloud.
  • UPI (User provisioned infrastructure cluster) : l’installation sera d’avantage manuelle, offrant plus de libertés et de configurations. Il faudra notamment provisionner l’infrastructure (instances, composants réseaux etc.) avant d’utiliser les fichiers générés par l’installeur pour configurer les nœuds de notre cluster.

Dans ce blog post, nous allons dans un premier temps détailler les différentes étapes relatives au processus d’installation d’Openshift dans un contexte UPI. Ensuite, nous listerons les prérequis nécessaires et les configurations associées pour installer Openshift sur AWS avec Terraform (IaC.) Les spécificités propres au cloud public AWS seront abordées.

Processus d’installation

Général

L’installation UPI va se baser sur des fichiers ignitions (amorçages en français).

Ces fichiers ignitions seront utilisés par les instances EC2 (master et worker nodes) pour configurer au démarrage le système d’exploitation RH CoreOS.

Afin de générer ces fichiers ignitions, il faudra fournir à l’installeur OCP, la configuration de notre cluster via un fichier install-config.yaml. L’installeur va ensuite générer dans un premier temps les manifests puis les fichiers ignitions.

Nous hébergerons ces fichiers dans un bucket S3 et nos instances utiliseront ces fichiers pour procéder à leurs configurations. Une instance supplémentaire de boostrap sera également à provisionner pour lancer le processus d’installation et de configuration du cluster.

Processus

Certes, il n’est pas nécessaire de comprendre le processus en détails pour administrer un cluster Openshift. Cependant, cela peut être utile dans le cas où vous devriez debugger un problème lors de l’installation.

Le processus peut être divisé en 5 étapes.

Dans un premier temps, les fichiers ignitions générés par l’installeur OCP vont être récupérés par la machine de bootstrap. Un ETCD dédié va être provisionné. Il sera notamment utilisé pour stocker la configuration du cluster

Ensuite, les master nodes vont récupérer leurs configurations et la machine de boostrap va déployer un control plane temporaire sur le port 22623.

Via ce control plane temporaire, un cluster ETCD sera provisionné sur les 3 masters nodes et un control plane de production sera accessible sur le port 6443.

A partir de ce stade, le serveur de bootstrap devient inutile et pourra être supprimé après la fin de l’installation. La suppression étant automatique dans le cas d’une installation IPI.

Pour terminer, les workers nodes sont configurés et le cluster OCP installé.

Architecture

Ici, un exemple d’architecture possible pour notre cluster OCP sur le cloud AWS.

Nous pouvons observer :

  • Un VPC pour héberger notre infrastructure.
  • Le bucket S3 qui sera utilisé pour héberger les fichiers ignitions.
  • Les instances du cluster et le serveur bootstrap dans des réseaux privées.
  • Un serveur bastion dans le réseau public pour suivre et debugger l’installation.
  • 3 Load balancers :
    • Un classic load balancer qui sera automatiquement provisionné par l’installeur pour le workload (applications)
    • Un network load balancer pour le control plane temporaire évoqué précédemment (port 22623), qui permettra au serveur de bootstrap de configurer les master nodes.
    • Un network load balancer pour le control plane de production (port 6443) qui permettra de configurer les workers nodes et d’utiliser le cluster OCP une fois l’installation terminée.

Pour provisionner ces ressources, l’utilisation de Terraformpeut être judicieuse afin de rester dans un contexte d’IaC.

Il est intéressant de provisionner dans un premier temps l’infrastructure AWS à l’exception des noeuds du cluster. Dans un second temps, nos instances EC2 workers et masters, une fois que toutes les entrées DNS sont provisionnées.

Prérequis

Amazon Web Services

Afin de provisionner notre infrastructure, certaines considérations sont à prendre en compte.

Pour commencer, le type d’instance EC2 doit répondre à certains prérequis hardware :

Ensuite, il est important de noter que les AMI sont dépendantes de la région AWS utilisée :

En outre, les prérequis suivants seront nécessaires :

  • Un compte AWS
  • Un utilisateur IAM avec le rôle SystemAdministrator
  • Une AWS Key pour utiliser Terraform à travers l’API AWS
  • Un nom de domaine
  • Un certificat SSL pour la console Openshift
  • Un serveur Bastion (EC2 t2.micro) pour suivre l’installation (cf schéma d’architecture)
  • Un bucket S3 (cf schéma d’architecture)

Laptop

Afin de lancer la création des fichiers ignitions, la création de l’infrastructure et du cluster OCP, les prérequis suivants seront à remplir sur votre environnement de travail :

Configuration

Génération des fichiers ignitions

Sur votre laptop, créer un fichier install-config.yaml dans un dossier spécifique (exemple : installation_dir) depuis le template suivant fourni par la documentation Openshift :

apiVersion: v1
baseDomain: example.com 
credentialsMode: Mint 
controlPlane:   
  hyperthreading: Enabled 
  name: master
  platform:
    aws:
      zones:
      - us-west-2a
      - us-west-2b
      rootVolume:
        iops: 4000
        size: 500
        type: io1 
      type: m5.xlarge
  replicas: 3
compute: 
- hyperthreading: Enabled 
  name: worker
  platform:
    aws:
      rootVolume:
        iops: 2000
        size: 500
        type: io1 
      type: c5.4xlarge
      zones:
      - us-west-2c
  replicas: 3
metadata:
  name: test-cluster 
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OpenShiftSDN
  serviceNetwork:
  - 172.30.0.0/16
platform:
  aws:
    region: us-west-2 
    userTags:
      adminContact: jdoe
      costCenter: 7536
    amiID: ami-96c6f8f7 
    serviceEndpoints: 
      - name: ec2
        url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com
fips: false 
sshKey: ssh-ed25519 AAAA... 
pullSecret: '{"auths": ...}'

Modifier et compléter ce fichier suivant la configuration désirée puis lancer la commande :

    openshift-install create manifests --dir=installation_dir/

Vous constaterez que votre fichier install-config.yml a été remplacé par des manifests Openshift.

Ensuite, lancer la commande suivante pour créer les ignitions files :

    openshift-install ignition-configs --dir=installation_dir/

Votre dossier d’installation doit à présent contenir les fichiers suivants :

  • Un répertoire auth contenant le kubeconfig et le password de l’utilisateur kubeadmin
  • les fichiers ignitions
  • un fichier metadata.json

Ce fichier metadata.json contient des informations importantes pour votre infrastructure.

En effet, le clusterID et l’infraID doivent notamment être utilisés pour tagger vos ressources pour le bon déroulement de l’installation.

Configuration IaC et spécificités AWS

Le code Terraform ne sera pas abordé en détails dans ce blog post mais voici les principaux points clefs :

  • Il peut être judicieux de créer des modules Terraform pour provisionner l’infrastructure et le cluster OCP.
  • Utiliser un remote state pour des raisons évidentes de sécurité.
  • Penser à utiliser le fichier terraform.tfvars pour surcharger les variables propre à l’installation de votre cluster et rendre votre code réutilisable pour plusieurs clusters.
  • Les fichiers ignitions doivent être stockés dans un bucket S3 (ou un serveur HTTP ou FTP.)
  • N’oubliez pas de gérer les ressources DNS, les Network Loadbalancers, réseaux (Security Group, VPC, subnets) directement dans vos manifests.
  • Il faut également via l’IaC créer les zones DNS publiques et reverses. Penser à désactiver la gestion automatique des reverses DNS :

  • Pour que les instances EC2 récupérent les fichiers ignitions, l’utilisation des user data EC2 sera nécessaire :

  • Tagger les Instances EC2 et la zone DNS principale avec les valeurs récupérées dans le metadata.json en vous référant à la documentation :

  • Ajouter le rôle AdministratorAccess Access aux instances EC2 :

Provisionnement

Une fois vos fichiers ignitions hébergés sur le bucket S3 et la préparation des vos manifests Terraform réalisée, vous pouvez lancer le provisionnement de l’infrastructure puis du cluster avec Terrraform (terraform plan, terraform apply).

Pour suivre l’installation de votre cluster, se connecter sur le serveur bastion puis sur le serveur bootstrap et lancer la commande suivante :

    journalctl --unit=bootkube.service

Cette documentation vous permettra de debugger facilement tout problème éventuel.

L’installation terminée, il reste cependant deux étapes pour accéder à votre cluster de manière sécurisée.

  • Accepter les certificats des workers pour les faire rejoindre le cluster :
oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"n"}}{{end}}{{end}}' | xargs oc adm certificate approve
watch oc get nodes
  • Mettre en place les certificats SSL pour votre console Openshift :
oc create configmap custom-ca 
   --from-file=ca-bundle.crt=/home/ec2-user/certificates/mycluster/mycluster.crt 
   -n openshift-config

oc get configmap custom-ca -n openshift-config -oyaml

oc create secret tls certificate 
  --cert=/home/ec2-user/certificates/mycluster/mycluster.crt 
  --key=/home/ec2-user/certificates/mycluster/mycluster.key 
  -n openshift-ingress

oc patch ingresscontroller.operator default 
     --type=merge -p 
     '{"spec":{"defaultCertificate": {"name": "certificate"}}}' 
     -n openshift-ingress-operator

watch oc -n openshift-ingress get pods

Vous devriez à présent pouvoir joindre votre console et vous connecter avec le compte kubeadmin !

Sources

Laisser un commentaire

  Edit this page