Déployer Cloud Foundry sur Kubernetes en utilisant KubeCF, AKS-Engine et CF-Operator …

Image for post
Image for post

our 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 :

Image for post
Image for post
Image for post
Image for post
kubernetes.json

Le cluster AKS est présent et opérationnel dans Azure :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

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 :

Image for post
Image for post
Image for post
Image for post

Pour la suite, j’ai besoin d’installer Helm 3 dans ce cluster et je récupère le binaire depuis Github :

Image for post
Image for post

- 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 :

Image for post
Image for post
Image for post
Image for post

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] }'
Image for post
Image for post

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) :

Image for post
Image for post
values.yaml

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
Image for post
Image for post

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 :

Image for post
Image for post

Un lancement des Pods avec ces valeurs s’opèrent dans le cluster (après une dizaine de minutes) :

Image for post
Image for post

Je charge CF CLI depuis Github pour me connecter à Cloud Foundry :

Image for post
Image for post
Image for post
Image for post

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 :

Image for post
Image for post

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}"
Image for post
Image for post

Je crée mon Espace et mon Organisation :

$ cf create-org MAS
$ cf create-space TEST -o MAS
$ cf target -o MAS
Image for post
Image for post

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
Image for post
Image for post

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
Image for post
Image for post
Image for post
Image for post

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
Image for post
Image for post

Connexion à Stratos avec les mêmes identifiants utilisés avec le client CF :

Image for post
Image for post
Image for post
Image for post

Je peux visualiser l’application lancée précédemment :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

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 :

Image for post
Image for post

visualisable dans la console Stratos :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Rapide test de mise à l’echelle horizontale et verticale de cette application :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

On peut visualiser les Pods engendrés par cette application dans le cluster Kubernetes :

Image for post
Image for post

également via Weave Scope :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Avec accès à l’application via la route fournie dans Cloud Foundry :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Quelques liens sur le sujet :

ubeCF 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 …

Image for post
Image for post

À suivre …

Above the clouds, the sky is always blue ...

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store