Créer son cluster Kubernetes avec RKE et lancement de RancherVM pour y orchestrer ses VM …
Je commence ici par créer une instance dans Hetzner Cloud qui va supporter Rancher Server qui est sensé depuis la version 2.0 être multi-cloud :
Lancement de la VM dans Hetzner Cloud :
avec cette commande pour lancer le container Docker avec l’image du serveur Rancher :
docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher
L’interface graphique de Rancher Server devient accessible :
Je vais lancer 3 instances bare metal sur Scaleway en CentOS 7 via la gamme de Serveurs C2M dotés de processeurs 8 cœurs Intel Atom x86–64 et 16 Go de RAM ainsi qu’un débit de 2*2,5 Gbit/seconde au niveau des cartes réseau :
Je peux utiliser la ligne de commande avec le binaire scw disponible sur github pour les créer et les contrôler :
et je lance mes 3 instances :
Je peux vérifier que les extensions Virtualisation sont présentes dans ces instances :
et j’utilise le binaire RKE disponible sur github pour créer mon cluster Kubernetes. Rancher Kubernetes Engine (RKE) est un installateur Kubernetes léger qui prend en charge l’installation sur des serveurs nus ouvirtualisés. RKE est sensé résoudre un problème commun à la communauté Kubernetes : la complexité de l’installation. Avec RKE, l’installation de Kubernetes est normalement simplifiée, quels que soient les systèmes d’exploitation ou les plates-formes utilisées :
Les binaires sont à récupérer et à installer sur sa station :
et je lance cette commande pour initier la création du cluster Kubernetes :
rke config --name cluster.ymlOn répond aux différentes questions et on obtient ce fichier de configuration en YAML avec les adresses IP des instances sur Scaleway :
avec ce fichier généré nommé ici cluster.yml
# If you intened to deploy Kubernetes in an air-gapped environment,
# please consult the documentation on how to configure custom RKE images.
nodes:
- address: 163.172.190.60
port: "22"
internal_address: 10.5.69.29
role:
- controlplane
- worker
- etcd
hostname_override: master
user: centos
docker_socket: /var/run/docker.sock
ssh_key: ""
ssh_key_path: /home/cert/.ssh/id_rsa
labels: {}
- address: 212.47.243.180
port: "22"
internal_address: 10.1.70.145
role:
- worker
- etcd
hostname_override: node1
user: centos
docker_socket: /var/run/docker.sock
ssh_key: ""
ssh_key_path: /home/cert/.ssh/id_rsa
labels: {}
- address: 212.47.233.58
port: "22"
internal_address: 10.5.70.215
role:
- worker
- etcd
hostname_override: node2
user: centos
docker_socket: /var/run/docker.sock
ssh_key: ""
ssh_key_path: /home/cert/.ssh/id_rsa
labels: {}
services:
etcd:
image: ""
extra_args: {}
extra_binds: []
extra_env: []
external_urls: []
ca_cert: ""
cert: ""
key: ""
path: ""
snapshot: false
retention: ""
creation: ""
kube-api:
image: ""
extra_args: {}
extra_binds: []
extra_env: []
service_cluster_ip_range: 10.43.0.0/16
service_node_port_range: ""
pod_security_policy: false
kube-controller:
image: ""
extra_args: {}
extra_binds: []
extra_env: []
cluster_cidr: 10.42.0.0/16
service_cluster_ip_range: 10.43.0.0/16
scheduler:
image: ""
extra_args: {}
extra_binds: []
extra_env: []
kubelet:
image: ""
extra_args: {}
extra_binds: []
extra_env: []
cluster_domain: cluster.local
infra_container_image: ""
cluster_dns_server: 10.43.0.10
fail_swap_on: false
kubeproxy:
image: ""
extra_args: {}
extra_binds: []
extra_env: []
network:
plugin: weave
options: {}
authentication:
strategy: x509
options: {}
sans: []
addons: ""
addons_include: []
system_images:
etcd: rancher/coreos-etcd:v3.2.18
alpine: rancher/rke-tools:v0.1.13
nginx_proxy: rancher/rke-tools:v0.1.13
cert_downloader: rancher/rke-tools:v0.1.13
kubernetes_services_sidecar: rancher/rke-tools:v0.1.13
kubedns: rancher/k8s-dns-kube-dns-amd64:1.14.10
dnsmasq: rancher/k8s-dns-dnsmasq-nanny-amd64:1.14.10
kubedns_sidecar: rancher/k8s-dns-sidecar-amd64:1.14.10
kubedns_autoscaler: rancher/cluster-proportional-autoscaler-amd64:1.0.0
kubernetes: rancher/hyperkube:v1.11.1-rancher1
flannel: rancher/coreos-flannel:v0.9.1
flannel_cni: rancher/coreos-flannel-cni:v0.2.0
calico_node: rancher/calico-node:v3.1.1
calico_cni: rancher/calico-cni:v3.1.1
calico_controllers: ""
calico_ctl: rancher/calico-ctl:v2.0.0
canal_node: rancher/calico-node:v3.1.1
canal_cni: rancher/calico-cni:v3.1.1
canal_flannel: rancher/coreos-flannel:v0.9.1
wave_node: weaveworks/weave-kube:2.1.2
weave_cni: weaveworks/weave-npc:2.1.2
pod_infra_container: rancher/pause-amd64:3.1
ingress: rancher/nginx-ingress-controller:0.16.2-rancher1
ingress_backend: rancher/nginx-ingress-controller-defaultbackend:1.4
metrics_server: rancher/metrics-server-amd64:v0.2.1
ssh_key_path: ~/.ssh/id_rsa
ssh_agent_auth: false
authorization:
mode: rbac
options: {}
ignore_docker_version: false
kubernetes_version: ""
private_registries: []
ingress:
provider: ""
options: {}
node_selector: {}
extra_args: {}
cluster_name: ""
cloud_provider:
name: ""
prefix_path: ""
addon_job_timeout: 0
bastion_host:
address: ""
port: ""
user: ""
ssh_key: ""
ssh_key_path: ""
monitoring:
provider: ""
options: {}Au préalable, j’installe le moteur Docker sur ces instances :
On lance alors l’installation du cluster Kubernetes avec RKE :
rke upet l’installation se termine après quelques minutes …
Je peux vérifier la présence du cluster avec le client kubectl et les credentials fourni dans un fichier kube_config_cluster.yml :
qu’on peut migrer vers .kube/config :
et je peux importer ce nouveau cluster dans le serveur Rancher :
pour cela, je dois lancer un manifest à télécharger depuis le serveur Rancher :
et il apparait dans le tableau de bord du serveur Rancher :
Je peux passer à l’installation de RancherVM. RancherVM permet de créer des VMs qui tournent à l’intérieur de pods Kubernetes, appelés VM Pods. Dans la théorie, il y a un container qui exécute une instance de machine virtuelle. On peut empaqueter alors n’importe quelle image QEMU/KVM en tant qu’image Docker, la distribuer en utilisant n’importe quel registre Docker tel que DockerHub, et l’exécuter sur RancherVM.
que l’on connaissait aupravant depuis quelques années pour créer des systèmes convergés mixant VM et containers :
RancherVM étend l’API Kubernetes avec des définitions de ressources personnalisées, ou CRD. Les utilisateurs définissent une spécification VM CRD détaillant l’image de base, la quantité de ressources de calcul et les paires de clés autorisées à ouvrir une session SSH. Un contrôleur Kubernetes crée des VM pods si nécessaire pour atteindre la spécification désirée et le reflète dans le statut du CRD.
Et dans cette optique, j’installe un serveur NFS sur le noeud maître du cluster (l’utilisation d’un partage avec par exemple Ceph ou GlusterFS pourrait fonctionner)
avec un partage en /var/lib/rancher/vm-shared :
et je vérifie que le démon du serveur NFS est actif :
et je peux créer un point de montage en /var/lib/rancher/vm sur les trois noeuds du cluster :
et je fais un test sur ce point de montage pour vérifier qu’il est bien actif :
Idem sur les autres noeuds du cluster :
Et je peux déployer RancherVM via un manifest présent sur le dépôt Github de Rancher :
$ kubectl create -f https://raw.githubusercontent.com/rancher/vm/master/deploy/ranchervm.yaml
et je vérifie que le déploiement des POD et service s’est bien déroulé :
$ kubectl -n ranchervm-system get pods$ kubectl -n ranchervm-system get svc/frontend
et le dashboard est accessible via le port TCP 31716 fourni viaNodePort (en l’absence ici d’une IP externe fournie par l’Ingress Controller). RancherVM est livré avec une interface utilisateur Web pour gérer les clés publiques, les nœuds de calcul, les machines virtuelles et l’accès à la console VNC à partir d’un navigateur Web :
Je commence par créer une clé publique via un manifest :
Idem pour une machine virtuelle :
et je lance le tout :
Et je peux multiplier les instances Ubuntu depuis le tableau de bord (après un temps non négligeable, processeur Intel Atom oblige …) :
Les points de montage NFS servent théoriquement à la migration de ces instances au sein de POD dans Kubernetes :
Un développement de RancherVM qui n’est pas encore terminé (idem pour certaines limitations de RKE) mais à regarder quand même. Surtout que des technologies alternatives comme KubeVirt ou Virtlet existent pour transformer Kubernetes en orchestrateur de machines virtuelles …
A suivre ! …
