KaaS – Déployer un cluster de travail

Installation du cluster de travail

Prérequis

• Un datacenter virtuel
• Un réseau routé avec accès à internet (snat)
• Résolution DNS internet
• La fonctionnalité de LoadBalancing activée (demande à effectuer)
• Cluster de bootstrap déployé
• Les outils de ligne de commande : Outils
• Pour IaaS Interne seulement : Source NAT pour Access API

L’ensemble des étapes ci-dessous doivent être réalisées depuis le cluster de management, c’est à dire connecté sur ce cluster via kubectl

NOTE : Si vous n’avez pas encore déployé un cluster de management dans votre environnement, merci de vous reporter au processus de déploiement via la page ci-dessous avant de continuer

• KaaS Standard – Parcours de déploiement.

Pour vérifier sur quel cluster vous êtes connecté, vous pouvez utiliser les commandes ci-dessous.

# kubectl config current-context

and 

# kubectl get nodes

Déploiement

Préparation du fichier de configuration du cluster à créer

L’outil clusterctl s’appuie sur des fichiers de templates (fournis par VMware dans notre cas) ainsi que d’un fichier de configuration avec l’ensemble des paramètres requis pour la création.

Le fichier de configuration d’exemple se situe : ~/.cluster-api/clusterctl.yaml

Nous l’utilisons donc comme base pour notre cluster wrk01

cp ~/.cluster-api/clusterctl.yaml wrk01-config.yaml

Remplissez le fichier values.yml précédemment copié

Le fichier ***-config.yml est utilisé pour renseigner l’ensemble des informations nécessaires à Cluster API pour déployer un cluster.

Les autres paramètres peuvent être ignorés

Générez le fichier yaml de création.

clusterctl generate cluster mgt01 --config mgt01-config.yaml -f v1.22.9-crs > mgt01.yaml

Appliquez le fichier yaml pour lancer la création du cluster.

Puis attendez que le cluster soit créé :

1. Vérifiez que l’objet Cluster est en phase Provisionned via la commande : kubectl get cluster
2. Attendez que tous les noeuds de master soient en status READY via la commande : kubectl get kubeadmcontrolplane

kubectl apply -f wrk01.yaml

# kubectl get kubeadmcontrolplane

NAME                   CLUSTER   INITIALIZED   API SERVER AVAILABLE   REPLICAS   READY   UPDATED   UNAVAILABLE   AGE   VERSION
wrk01-control-plane    wrk01     true          true                   1          1       1         0             24m   v1.22.9+vmware.1v1.22.9+vmware.1

Grâce au ClusterResourceSet les PODS de CNI, CSI et CPI sont déployés automatiquement, cependant ils leur manquent quelques éléments de configuration que nous allons ajouter maintenant. C’est pourquoi ces PODS ne sont pas encore running sur le nouveau cluster créé.

Pour cela il faut bien être connecté au cluster de management et non pas au nouveau cluster.

Modifiez les 6 premières lignes de commandes fournies à droite et appliquez l’ensemble

Créer les secrets :

CLUSTERNAME : Nom du cluster de travail que l’on est en train de créer

MGT : chemin vers le kubeconfig de notre cluster de management

VCDHOST: URL de la console vCloud Director

ORG: nom de votre organisation

OVCD: nom du datacenter virtuel ou se situe le cluster

ONETWORK: nom du réseau VCD ou se situe le cluster

Après quelques minutes tous les PODS doivent être en phase RUNNING sur le cluster wrk01

CLUSTERNAME=mgt01
MGT=~/.kube/kube-bootstrap01
VCDHOST=https://*******.com/
ORG=***
OVDC=***
ONETWORK=****

WRK=~/.kube/kube-${CLUSTERNAME}
clusterctl get kubeconfig ${CLUSTERNAME} > ${WRK}
export CLUSTERID=$(kubectl --kubeconfig=${MGT} get vcdclusters ${CLUSTERNAME} -o jsonpath="{.status.infraId}")
kubectl --kubeconfig=${WRK} -n kube-system create secret generic vcloud-clusterid-secret --from-literal=clusterid=${CLUSTERID}

export REFRESH_TOKEN=$(kubectl --kubeconfig=${MGT} get secret capi-user-credentials -o jsonpath="{.data.refreshToken}" | base64 --decode)
kubectl --kubeconfig=${WRK} -n kube-system create secret generic vcloud-basic-auth --from-literal=refreshToken=${REFRESH_TOKEN} --from-literal=username="" --from-literal=password=""

Créer les configmaps

Utilisez les deux commandes ci-contre pour créer les configmaps requis.

Il est possible de les customiser notamment en choisissant un vipSubnet.

echo "apiVersion: v1
kind: ConfigMap
metadata:
    name: vcloud-csi-configmap
    namespace: kube-system
data:
    vcloud-csi-config.yaml: |+
        vcd:
          host: ${VCDHOST}
          org: ${ORG}
          vdc: ${OVDC}
          vAppName: ${CLUSTERNAME}
        clusterid: ${CLUSTERID}
immutable: true" | kubectl apply --kubeconfig=${WRK} -f -

echo "apiVersion: v1
kind: ConfigMap
metadata:
      name: vcloud-ccm-configmap
      namespace: kube-system
data:
      vcloud-ccm-config.yaml: |+
        vcd:
          host: ${VCDHOST}
          org: ${ORG}
          vdc: ${OVDC}
        loadbalancer:
          oneArm:
            startIP: \"192.168.8.2\"
            endIP: \"192.168.8.100\"
          ports:
            http: 80
            https: 443
          network: ${ONETWORK}
          vipSubnet: \"\"
          certAlias: ${CLUSTERID}-cert
          enableVirtualServiceSharedIP: false # supported for VCD >= 10.4
        clusterid: ${CLUSTERID}
        vAppName: ${CLUSTERNAME}
immutable: true" | kubectl apply --kubeconfig=${WRK} -f -

Après quelques instants tous les PODS doivent être Running sur le cluster et les composants machinedeployment sur le cluster de management doivent être en status READY et Phase Running

# kubectl get machinedeployment

NAME          CLUSTER   REPLICAS   READY   UPDATED   UNAVAILABLE   PHASE     AGE   VERSION
mgt01-md-0    mgt01     1          1       1         0             Running   28m   v1.22.9+vmware.1

Supprimer un cluster

En étant connecté sur votre cluster de bootstrap, lancez la commande kubectl delete cluster

kubectl delete cluster CLUSTER-NAME

Créer une classe de stockage

En utilisant les solutions de KaaS de CloudAvenue vous êtes en mesure de consommer du stockage disponible dans votre Datacenter virtuel automatiquement afin d’avoir des Volumes Persistent pour vos PODS Kubernetes.

Pour cela, au moins une classe de stockage kubernetes doit être créée sur votre cluster. Cette classe de stockage va pointer vers la stratégie de stockage vCloud Director de votre choix.

Créez un fichier mystorageclass.yaml et copiez à l’intérieur le contenu fourni dans la colonne de droite. Remplacez la valeur YOUR_STORAGE_POLICY par le nom de la stratégie de stockage vCloud Director de votre choix.

L’exemple fourni crée une classe de stockage qui sera celle par défaut dans votre cluster. Si vous crééz plusieurs classes où si simplement vous ne voulez pas avoir de classe de stockage par défaut, changez le paramètre storageclass.kubernetes.io/is-default-class à false.

---
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
  name: storage-class-name
provisioner: named-disk.csi.cloud-director.vmware.com
reclaimPolicy: Delete
parameters:
  storageProfile: "YOUR_STORAGE_POLICY"
  filesystem: "ext4"

Configurer le vipSubnet pour les services externes

Le vipSubnet correspond au réseau externe de vCloud Director à utiliser pour exposer un service via un Load balancer externe au cluster.

Quand un service de type Load Balancer est crée, un Virtual Service est automatiquement crée dans la configuration du LoadBalancer VCD, puis une règle de DNAT est automatiquement ajoutée pour pointer vers vers ce Virtual Service.

L’IP utilisée pour cette règle de DNAT est une IP provenant du réseau de vipSubnet que l’on défini ici.

Pour choisir ou simplement choisir ce réseau externe, merci de suivre les étapes suivantes.

Récupérez dans un fichier la configuration actuelle du configmap

kubectl -n kube-system get cm/vcloud-ccm-configmap -o yaml > vcloud-ccm-configmap.yaml

Récupérez la version actuelle du ccm.

(ceci sera utilisé plus loin dans la procédure)

# kubectl get pod -n kube-system  -l app=vmware-cloud-director-ccm -o=jsonpath='{range .items[*]}{.status.containerStatuses[0].image}{"\r\n"}{end}'

projects.registry.vmware.com/vmware-cloud-director/cloud-provider-for-cloud-director:1.1.0.latest

Modifiez le paramètre vipSubnet dans le fichier précédemment créé

apiVersion: v1
data:
  vcloud-ccm-config.yaml: |
    vcd:
      host: "https://console1.cloudavenue.orange-business.com"
      org: "MYORG01"
      vdc: "MYVDC01"
      vAppName: mycluster01
      network: "myprodnetwork"
      vipSubnet: "10.102.122.102/26"
    loadbalancer:
      oneArm:
        startIP: "192.168.8.2"
        endIP: "192.168.8.100"
      ports:
        http: 80
        https: 443
immutable: true
kind: ConfigMap
metadata:
  name: vcloud-ccm-configmap
  namespace: kube-system

Supprimez la configmap & le déploiement du ccm

kubectl -n kube-system delete cm/vcloud-ccm-configmap

kubectl -n kube-system delete deploy/vmware-cloud-director-ccm

Recréez la configmap avec la nouvelle valeur.

Recréez le déploiement du ccm pour prendre en compte le nouveau vipSubnet.

En fonction de la version installée sur votre cluster, le lien du fichier yaml à appliquer peut varier. Merci d’utiliser l’url récupérée lors de la seconde étape.

kubectl apply -f vcloud-ccm-configmap.yaml
kubectl apply -f https://raw.githubusercontent.com/vmware/cloud-provider-for-cloud-director/1.1.0/manifests/cloud-director-ccm.yaml

Récupérer un refreshToken VCD

• Ouvrez votre console vCloud Director avec le compte que vous souhaitez utiliser pour créer vos clusters (compte de service)
• Dans le coin en haut à droite de la page, cliquez sur les 3 points verticaux.
• Cliquez sur Préférence utilisateur
• Dans la section Jetons d’accès cliquez sur Nouveau
• Donnez un nom à ce token puis cliquez sur Créer
• Copiez le jeton. Ce jeton est à garder précieusement et bien sécurisé.