¶ Aperçu de Mirantis Kubernetes Engine (MKE) :
MKE anciennement Docker EE fourni une UI (anciennement appelé Universal Control Plane / UCP) :
Cette UI permet de contrôler le cluster (Swarm + Kubernetes).
Voici la documentation officielle de MKE : https://docs.mirantis.com/welcome/
¶ Installer MKE :
La meilleure manière d'essayer MKE est de passer par Mirantis Launchpad ici
Voici comment installer MKE :
- Déployer deux machines virtuelles Ubuntu (20.04, ne fonctionne pas avec 22.04 au moment ou j'écris ce wiki)
- Mettre à jour les machines sudo apt update
- On doit pouvoir se connecter aux deux machines via SSH (clé SSH). Il faut donc être dans le
authorized_keys
$ ssh-keygen
$ cat ~/.ssh/id_rsa.pub
# Mettre la id_rsa.pub dans le authorized_keys de l'autre serveur
- Télécharger et installer launchpad (uniquement sur le manager) :
# https://github.com/Mirantis/launchpad/releases/latest vérifier la dernière mise à jour ici
$ wget https://github.com/Mirantis/launchpad/releases/download/v1.5.9/launchpad_linux_amd64_1.5.9 -O launchpad
$ chmod +x launchpad
- S'enregistrer :
ubuntu@docker-01-1:~$ ./launchpad register
> Name AC
> Email *******@mail.fr
> Company AC
> I agree to Mirantis Launchpad Software Evaluation License Agreement https://github.com/Mirantis/launchpad/blob/master/LICENSE Yes
- Initialiser la configuration :
./launchpad init > launchpad.yaml
- Modifier la configuration avec les bonnes informations :
# Exemple
apiVersion: launchpad.mirantis.com/mke/v1.4
kind: mke
metadata:
name: my-mke-cluster
spec:
hosts:
- ssh:
address: <manager_public_IP>
user: ubuntu
port: 22
keyPath: ~/.ssh/id_rsa
role: manager
- ssh:
address: <worker_public_IP>
user: ubuntu
port: 22
keyPath: ~/.ssh/id_rsa
role: worker
mke:
version: 3.7.16
mcr:
version: 23.0.15
cluster:
prune: false
- Puis appliquer la configuration :
./launchpad apply
# Peut prendre 15/20 minutes
- Une fois la configuration appliquée, accéder à l'interface via l'IP du noeud :
Voici à quoi ressemble l'interface de MKE :
¶ Mirantis Kubernetes Engine :
Docker MKE est la solution de management du cluster de MKE.
- MKE va aider à manager les applications à travers d’une interface.
- MKE est une application conteneurisée qui tourne sur MKE.
Une fois MKE déployé, on interagit plus avec Docker Engine, mais avec MKE.
Voici la configuration pour MKE :
¶ Ajouter un noeud au cluster
Dans un premier temps, ajouter un worker au swarm avec MKE :
- Cliquer sur
Add nodes(sous les graphiques sur la page principale) et suivre les indications :
¶ Déploiement d'un service "global" dans Swarm avec MKE
Une fois crée, aller dans Swarm, Service → Create puis dans Scheduling sélectionner Global :
Une fois le service crée (par exemple nginx pour être original) :
¶ MKE - Contrôle d'accès
Docker MKE Permet d’avoir un contrôle d’accès assez poussé qui va nous permettre de définir différents aspect comme “qui peut créer et éditer les containers dans ce swarm ?”
- Un sujet représente un utilisateur, l’équipe ou une organisation. (https://docs.mirantis.com/mke/3.6/ref-arch/rbac.html)
- Un sujet se voit à son tour attribuer un rôle approprié
- User : Utilisateur individuel
- Organization : Un groupe d’utilisateurs qui partage un groupe de permission, défini par le rôle de l’organisation
- Team : Un groupe d’utilisateurs qui partage un groupe de permission, défini par l’équipe elle même. Une équipe n'existe que dans le cadre d'une organisation
- Service Account : Objet Kubernetes qui permet à un workload d'accéder aux ressources du cluster attribuées à un espace de noms.
Un rôle est un ensemble de permission API qui peut être assigné à un certain sujet et collection.
Les collections incluent :
- Noeuds physiques/virtuels
- Containers
- Services
- Réseaux
- Volumes
- Secrets
- Configurations des apps
Voici un exemple, le sujet (ici l'user) a le droit Full Control sur toutes les resources du cluster Swarm :
¶ Aperçu du MSR : Mirantis Secure Registry :
Mirantis Secure Registry (anciennement Docker Trusted Registry) est la solution de registry Entreprise de Docker.
MSR donne des fonctionnalités pratiques pour les entreprises comme :
- Scan de sécurité
- Signature des images
- Controle d’accès
- Caching images
Pour faire tourner MSR :
- 16Go de RAM pour les noeuds faisant tourner MSR
- 2 vCPU
- 10Go disque
Pour installer MSR, tous les noeuds doivent :
- Être des workers managés par MKE
- Avoir un hostname fixe
MSR peut utiliser le stockage Amazon S3/Azure/Google cloud Storage pour stocker les images.
¶ Installation de MSR et intégration avec MKE
Aller dans admin → Admin Settings → Docker Trusted Registry :
- Sélectionner le bon “MKE node” comme ci-dessous :
la commande est générée automatiquement :
docker run -it --rm mirantis/dtr install --ucp-node docker-manager --ucp-username admin --ucp-url https://34.77.249.70 --ucp-insecure-tls
- Copier coller la commande sur le noeud sélectionné. Après ~5 minutes tout devrait s'être installé :
- Y accéder via l'IP du manager (dans notre cas) avec le login/mdp de MKE :
¶ Création d'un repo
Cliquer sur Repositories puis New repository en haut à droite :
Un repository public nécessitera tout de même de se connecter (docker login) pour pouvoir push une image :
$ docker login 1.2.3.4
Username: admin
Password:
Login Succeeded
$ docker push 1.2.3.4/kactica/test:v1
The push refers to repository [1.2.3.4/kactica/test]
1b9698f962dc: Pushed
v1: digest: sha256:99f98de8a0a27a7e1b3979238d17422ae3359573bda3beed0906da7e2d42e8c3 size: 529
¶ Backup des images MSR
¶ Backup des metadatas
MSR possède une commande pour faire un backup.
Cette commande ne rend pas le MSR indisponible, on peut donc le faire fréquemment.
docker run --log-driver none -i --rm mirantis/dtr backup --ucp-url https://34.77.249.70 -ucp-insecure-tls --ucp-username admin --ucp-password <password> > backup.tar
Dans l’exemple, on passe d’un registry de 120mo à un backup de 2,6 mo. Comment ?!
- Cette commande crée un backup de la configuration et des metadatas de l’image
- Ne backup pas les users/organisations de MKE. Ils peuvent être backup pendant le backup MKE
- Ne backup pas les images stockées dans le registry !
¶ Backup des images
On sait que MSR peut stocker les images à différents endroits :
- Filesystem (par défaut) : sous forme de volume (
/var/lib/docker/volumes), bind mount, NFS, stockage cloud (Amazon S3, Azure, GC Storage…)
Si les images sont stockées sous forme de volume alors sur l’interface (System → Storage) on peut trouver le nom du volume (ici : dtr-registry-7072e3498cda) :
On peut donc directement faire un backup depuis /var/lib/docker/volumes :
tar -czvf dtr-registry-7072e3498cda.tar.gz dtr-registry-7072e3498cda/
Si c’est sur un cloud, alors le backup se fera depuis le site (snapshot, disque haute dispo…)
¶ MSR - Haute disponibilité
MSR a été conçu pour scaler horizontalement. On peut ajouter autant de replicas que l’on veut.
Attention !
Si MSR utilise le stockage “filesystem” alors il faudra faire attention que chaque replica utilise le même chemin de stockage (Stockage partagé NFS par exemple) !
Pour joindre un MSR replica déjà crée auparavant :
docker run -it --rm mirantis/dtr join --ucp-insecure-tls
MSR possède différents endpoints afin de savoir si le replica est “healthy” :
/_ping:Checks if the MSR replica is healthy, and returns a simple JSON response. This is useful for load balancing and other automated health check tasks./nginx_status: Returns the number of connections handled by the NGINX MSR front end./api/v0/meta/cluster_status: Returns detailed information about all MSR replicas.
$ curl -k https://<ip_msr>/_ping
OK
$ curl -ksl -u admin:password https://<ip_msr>/api/v0/meta/cluster_status
{
"rethink_system_tables": {
"cluster_config": [
{
"heartbeat_timeout_secs": 10,
"id": "heartbeat"
}
],
"current_issues": [
],
"db_config": [
{
"id": "674ab369-4ccc-45cf-abfc-c3b0cb713eef",
"name": "dtr2"
},
...
Comme tout cluster HA pour avoir une haute disponibilité minimale MKE et MSR :
- 3 noeuds MKE
- 3 noeuds MSR
Trop de noeuds peut aussi mener à une perte de performance car les datas doivent se répliquer entre chaque replica !
¶ Tags immuable dans MSR :
Par défaut, les utilisateurs avec les droits lecture/écriture à un repo peuvent push le même tag plusieurs fois dans un même repository.
Si l’utilisateur push myapp:latest (en bleu), cela va écraser myapp:latest (en vert).
Le but est donc d’empêcher de laisser push 2x le même tag :
Pour rendre un repo immutable, aller dans l'onglet Settings du repo et passer immutability à On :
Lors de la création du repo, cliquer sur Montrer les paramètres avancés.
¶ MSR - cache
Selon notre situation géographique par rapport au serveur MSR, cela peut prendre plus ou moins de temps à push/pull une image.
Pour réduire ce temps de pull/push on peut déployer des MSR cache selon la situation géographique des utilisateurs :
MKE n’est pas nécessaire sur un serveur MSR de cache !
¶ Étapes de désinstallation de MSR
Lancer la commande ci-dessous :
docker run -it --rm mirantis/dtr destroy --ucp-insecure-tls
¶ Aperçu de swarm routing mesh
On sait déjà qu’on peut avoir plusieurs noeuds dans un cluster swarm.
Quand on crée un service, la tâche va être assignée à l’un d’entre eux.
Routing mesh active le fait que chaque noeud swarm puisse accepter les connexions sur les ports publiés pour n’importe quel service qui tourne sur le swarm. Même s’il n’y a pas de tâche qui tourne :
En accédant via l'IP du node3 sur le port 8080, j'accèderai donc à my-web.1 ou my-web.2 selon ou m'envoie le Load Balancer.
Dans le cas de MKE et MSR, ceux-ci ne sont pas des services. Ils ne profitent donc pas du routing mesh.
¶ Configuration de l'orchestrateur dans MKE
Docker MKE supporte les orchestrateurs Swarm et Kubernetes.
Quand on ajoute un noeud au cluster, la charge du nœud est managée par l’orchestrateur par défaut (Swarm ou Kubernetes).
Quand on installe Docker Enterprise, les nouveaux noeuds sont managés par Docker Swarm. Mais on peut changer l’orchestrateur par Kubernetes dans les paramètres.
Vous pouvez modifier l'orchestrateur actuel pour tout noeud joint à un cluster Docker Enterprise. Les types d'orchestrateur disponibles sont Kubernetes, Swarm, Mixed (seulement dans l'édition des noeuds).
Voici l'édition d'un noeud :
Mixed signifie que les deux types d'orchestration peuvent tourner sur le même noeud, ce n'est cependant pas recommandé en production.
Lorsque vous changez le type d'orchestration d'un nœud, les charges de travail existantes sont expulsées et ne sont pas migrées automatiquement vers le nouvel orchestrateur.
Pour changer un noeud de type Swarm en Kubernetes on peut aussi le faire en CLI (il est possible de mettre les deux!) :
docker node update --label-add com.docker.ucp.orchestrator.swarm=true <node-id>
docker node update --label-add com.docker.ucp.orchestrator.kubernetes=true <node-id>