Pour ceux qui ont déjà installé Cloud Foundry dans le passé, BOSH était le seul moyen d’installer et de gérer un cluster Cloud Foundry. Enfin, c’était avant l’arrivée de CF-Operator, Cloud Foundry Quarks, Eirini, et KubeCF …
Dans cette nouvelle expérience, je commence par lancer un cluster Kubernetes par l’entremise d’AKS-Engine. AKS Engine fournit des outils pratiques permettant d’amorcer rapidement via ARM (Azure Resource Manager), de créer, de détruire et de maintenir des clusters Kubernetes approvisionnés en ressources IaaS sur Azure. AKS Engine est également la bibliothèque utilisée par AKS pour effectuer ces opérations afin de fournir des implémentations de services gérés :
Après avoir cloné localement le dépôt d’AKS-Engine sur Github, je récupère le fichier JSON qui permet de profiter des machines virtuelles Spot dans Azure dans le cluster Kubernetes à provisionner. Les machines virtuelles Spot Azure vous donnent accès à une capacité de calcul Azure inutilisée en échange de remises importantes. Les tarifs Spot sont disponibles sur les machines virtuelles uniques, en plus de groupes de machines virtuelles identiques (VMSS — Virtual Machine Scale Sets). Cela vous permet de déployer sur Azure un plus large éventail de charges de travail tout en bénéficiant de prix réduits. Les machines virtuelles Spot offrent les mêmes caractéristiques que les machines virtuelles avec paiement à l’utilisation, et se distinguent en termes de tarification et de suppression. Les machines virtuelles Spot peuvent être supprimées à tout moment si Azure a besoin de capacité :
Au préalable, j’ai récupéré le binaire AKS-Engine sur Github :
et j’ai généré un principal du service Azure AD pouvant créer des ressources :
Je lance la création du nouveau cluster Kubernetes avec le binaire AKS-Engine :
Le cluster AKS est présent et opérationnel dans Azure :
Je bénéficie normalement du service de Load Balancing dans AKS-Engine mais pour initier mon plan d’adressage, j’ai initié un plan d’adressage avec ZeroTier dans ce cluster :
Pour la suite, j’ai besoin d’installer Helm 3 dans ce cluster et je récupère le binaire depuis Github :
- CF-Operator est un opérateur Kubernetes déployé via un Helm Chart qui installe une série de définitions de ressources personnalisées (CRD) qui convertissent les versions BOSH en ressources Kubernetes telles que des pods, des déploiements et des ensembles avec état. Cela n‘entraîne pas à lui seul un déploiement de Cloud Foundry.
- KubeCF est une version de Cloud Foundry déployée sous la forme d’un Helm Chart, principalement développée par SUSE, qui exploite CF-Operator.
- Eirini échange le backend Diego contre Kubernetes, ce qui signifie que lorsque vous poussez, vos applications s’exécutent en tant que pods Kubernetes à l’intérieur d’un ensemble avec état.
- En utilisant ces outils ensemble, on peut déployer un plan de contrôle Cloud Foundry et faire fonctionner les applications en tant que Pods dans Kubernetes.
Je lance le déploiement de CF-Operator dans le cluster via un Helm Chart :
$ kubectl create cf-operator$ helm install cf-operator \
--namespace cf-operator \
--set "global.operator.watchNamespace=kubecf" \
https://s3.amazonaws.com/cf-operators/release/helm-charts/cf-operator-v2.0.0-0.g0142d1e9.tgz
Je vérifie que les Pods / CRD sont bien lancés :
Pour définir les bons plans d’adressage à déclarer dans le fichier de configuration nommé values.yaml, je lance ces commandes :
$ kubectl cluster-info dump --output yaml \
| awk 'match($0, /cluster-cidr=(.*)/, cidr) { print cidr[1] }'$ kubectl cluster-info dump --output yaml \
| awk 'match($0, /service-cluster-ip-range=(.*)/, range) { print range[1] }'
d’où le fichier avec une configuration minimale pour le déploiement de Cloud Foundry (en prenant un domaine Wilcard qui pointera sur l’adresse IP du segment déclaré dans MetalLB qui sera attribuée au service nommé kubecf-router-public) :
Installation de KubeCF via un autre Helm Chart :
$ helm install kubecf \
--namespace kubecf \
--values values.yaml \
https://github.com/SUSE/kubecf/releases/download/v0.2.0/kubecf-0.2.0.tgz
avec ce fichier YAML minimal par défaut. Je possède l’adresse IP fournie par le service de Load Balancing via MetalLB pour le service nommé kubecf-router-public :
Un lancement des Pods avec ces valeurs s’opèrent dans le cluster (après une dizaine de minutes) :
Je charge CF CLI depuis Github pour me connecter à Cloud Foundry :
Avec le client CF déjà installé, je peux cibler et m’authentifier sur Cloud Foundry en utilisant l’URL du domaine qui correspond à celui enregistré dans le fichier de configuration values.yaml :
ce que je peux alors faire :
$ admin_pass=$(kubectl get secret \
--namespace kubecf kubecf.var-cf-admin-password \
-o jsonpath='{.data.password}' \
| base64 --decode)$ cf auth admin "${admin_pass}"
Je crée mon Espace et mon Organisation :
$ cf create-org MAS
$ cf create-space TEST -o MAS
$ cf target -o MAS
Je peux activer dans Cloud Foundry, Diego un système de gestion de containers auto-réparables qui tente de maintenir le nombre correct d’instances en cours d’exécution dans les cellules afin d’éviter les pannes et les plantages du réseau. Diego programme et exécute des tâches et des processus de longue durée :
$ cf enable-feature-flag diego_docker
Il est dès lors possible de lancer une image Docker via le client CF :
$ cf push fcdemo -o mcas/franceconnect-agent-demo:master -m 128M -k 384M
J’installe Stratos, une interface utilisateur Web (console) open source pour la gestion de Cloud Foundry. Cela permet aux utilisateurs et aux administrateurs de gérer les applications et d’effectuer des tâches de gestion du cluster :
$ cf push console -o splatform/stratos:stable -m 128M -k 384M
Connexion à Stratos avec les mêmes identifiants utilisés avec le client CF :
Je peux visualiser l’application lancée précédemment :
Autre test avec le lancement directement depuis un dépôt source récupéré depuis Github (avec encore une fois le démonstrateur FC) qui va engendrer le chargement des buildpacks dans Cloud Foundry :
visualisable dans la console Stratos :
Rapide test de mise à l’echelle horizontale et verticale de cette application :
On peut visualiser les Pods engendrés par cette application dans le cluster Kubernetes :
également via Weave Scope :
Avec accès à l’application via la route fournie dans Cloud Foundry :
On pourrait aller plus loin dans ce cluster Cloud Foundry via l’initiation de Pipelines de CI/CD via Concourse :
Quelques liens sur le sujet :
KubeCF et CF-Operator sont amenés à évoluer rapidement pour simplifier l’usage et le déploiement d’applications dans Kubernetes via … Cloud Foundry. En effet, avec ceci on a la possibilité de fournir une offre de type PaaS plus complète aux équipes de développement tout en profitant de déploiements dans Kubernetes. Cela permettrait aux équipes de développement de décider lequel de ces deux types de services ou d’applications convient le mieux en sélectionnant l’une de ces deux plate-formes voire les deux. Les équipes disposant d’applications de base pourraient les déployer en exécutant simplement un “cf push” par exemple …
À suivre …
