Oracle Cloud on Zwindler's Reflection

Un cluster Kubernetes gratuit pour vos labs persos ! - part 2

Tue, 23 May 2023 18:00:00 +0200

Cet article fait partie d’une suite d’articles sur l’installation d’un cluster Kubernetes sur le free tier d’Oracle Cloud Infrastructure :

L’avantage principal de ce tuto est qu’il est gratuit. L’inconvénient est que l’installation est relativement longue…

“Résumé des épisodes précédents”

Dans l’article précédent (que vous pouvez retrouver ici), on avait pris en main Oracle Cloud et installé k3s sur deux machines ARM du free tier.

A l’issue de l’article, on avait donc, pour rappel, un cluster Kubernetes fonctionnel avec un master et un worker, mais pas encore accessible ni vraiment utilisable sur Internet.

Dans cette partie, on va donc finaliser tous les petits bouts qui manquent pour avoir quelque chose de vraiment propre.

Creuse ton tunnel

Comme je le dis juste avant, on a un cluster fonctionnel. Si je me connecte sur la machine controlplane et que je lance la CLI kubectl, je pourrais interagir avec mon cluster Kubernetes.

Cependant, il est très probable que vous vouliez accéder à votre cluster flambant neuf sans avoir à vous connecter préalablement en SSH sur votre machine (enfin moi, c’est mon cas).

Et je n’ai pas envie non plus de publier l’API server (port 6443) de mon control plane sur Internet (en soi pour du POC, c’est faisable, mais ça ne me dit rien, perso).

Je vais donc monter un VPN wireguard entre ma machine et mon control plane. Dans un setup plus “pro”, on montera un bastion dans notre LAN privé du cloud provider pour ça. Ici, pour les besoins de l’article, je me contente de monter le peer directement entre le node controlplane et mon PC.

J’installe d’abord wireguard sur les deux machines, et je génère un couple clé publique/privée :

$ sudo apt install wireguard

$ sudo -i
$ cd /etc/wireguard/
$ umask 077; wg genkey | tee private.key | wg pubkey > public.key
$ exit

Récupérez le contenu de la clé publique de chaque machine, ainsi que leur IP publique.

Note : pour trouver rapidement l’IP publique de chez vous, vous pouvez utiliser des services comme dig +short myip.opendns.com @resolver1.opendns.com, curl http://4.ifcfg.me ou équivalent

Ensuite, je vais créer un fichier de configuration /etc/wireguard/oci0.conf sur mon pc. Dans mon cas, l’interface réseau s’appelle enp8s0

$ sudo -i
$ PEER_IP=IP.PUBLIQUE.DU.CONTROLPLANE
$ PEER_PUBLIC_KEY=CLE.PUBLIQUE.DE.VOTRE.CONTROLPLANE
$ cat > /etc/wireguard/oci0.conf << EOF
[Interface]
Address = 10.10.10.1/24
ListenPort = 55555
PrivateKey = `cat /etc/wireguard/private.key`

[Peer]
PublicKey = ${PEER_PUBLIC_KEY}
AllowedIPs = 10.10.10.2/32,10.0.0.0/24
Endpoint = ${PEER_IP}:55555
EOF
$ exit
$ wg-quick up oci0

Et on fait pareil sur le node controlplane (son interface réseau s’appelle enp0s6 dans mon cas).

$ sudo -i
$ PEER_IP=IP.PUBLIQUE.DU.PC
$ PEER_PUBLIC_KEY=CLE.PUBLIQUE.DE.VOTRE.PC
$ cat > /etc/wireguard/oci0.conf << EOF
[Interface]
Address = 10.10.10.2/24
ListenPort = 55555
PrivateKey = `cat /etc/wireguard/private.key`

[Peer]
PublicKey = ${PEER_PUBLIC_KEY}
AllowedIPs = 10.10.10.1/32
Endpoint = ${PEER_IP}:55555
EOF
$ exit
$ wg-quick up oci0

Comme les machines OCI disposent toutes d’un pare-feu iptables et aussi d’un pare-feu au niveau du réseau virtuel, on doit ouvrir les ports côté controlplane

# allow wireguard access from your own public IP address
$ iptables -I INPUT -s IP.PUBLIQUE.DU.PC -p udp --dport 55555 -j ACCEPT

# save rules
$ sudo netfilter-persistent save

Et côté console Oracle Cloud (Security list dans l’administration du VCN, je vous renvoie au précédent post où je détaille comment faire)

A partir de maintenant, votre PC à l’IP 10.10.10.1 et votre control plane l’IP 10.10.10.2. Les deux doivent pouvoir se pinger :

$ ping 10.10.10.1
$ ping 10.10.10.2

On devrait aussi pouvoir ping l’IP privée (interne) de notre controlplane depuis notre pc

$ ping 10.0.0.xxx

Si wireguard vous intéresse, il existe énormément de documentation sur Internet à ce sujet, à commencer par le site officiel.

Accéder au cluster depuis votre poste

On a maintenant un tunnel pour discuter de notre PC vers notre control plane Kubernetes, mais toujours pas la possibilité de discuter avec Kubernetes. Il reste encore une règle iptables à ajouter 😭.

Pour s’en convaincre, on tente de voir si le port répond depuis notre PC :

$ nc -zv 10.10.10.2 6443
nc: connect to 10.10.10.2 port 6443 (tcp) failed: No route to host
$ nc -zv 10.0.0.xxx 6443
nc: connect to 10.0.0.xxx port 6443 (tcp) failed: No route to host

Côté controlplane, on va donc autoriser le traffic provenant de wireguard (interface oci0) à se connecter à l’API server

# allow access to apiserver from wireguard interface
$ sudo iptables -I INPUT -i oci0 -p tcp --dport 6443 -j ACCEPT

# save rules
$ sudo netfilter-persistent save

Et maintenant, depuis notre PC :

$ nc -zv 10.10.10.2 6443
Connection to 10.10.10.2 6443 port [tcp/*] succeeded!
$ nc -zv 10.0.0.xxx 6443
Connection to 10.0.0.34 6443 port [tcp/*] succeeded!

Récupérez le contenu du fichier /etc/rancher/k3s/k3s.yaml sur le serveur controlplane. Créez un fichier k3s.yaml sur votre machine et remplacez la valeur server: https://127.0.0.1:6443 par server: https://10.10.10.2:6443.

Vous devriez maintenant avoir accès à votre cluster depuis votre PC !

$ export KUBECONFIG=k3s.yaml
$ kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system helm-install-traefik-crd-xdg7s 0/1 Completed 0 29d
kube-system helm-install-traefik-ncqzm 0/1 Completed 1 29d
kube-system svclb-traefik-084208f2-dcsqr 2/2 Running 0 29d
kube-system local-path-provisioner-5d56847996-x76zx 1/1 Running 5 (29d ago) 29d
kube-system svclb-traefik-084208f2-zw6bv 2/2 Running 7 (29d ago) 29d
kube-system coredns-7c444649cb-gg22s 1/1 Running 3 (29d ago) 29d
kube-system metrics-server-7b67f64457-r5c5n 1/1 Running 5 (29d ago) 29d
kube-system traefik-56b8c5fb5c-px5pc 1/1 Running 3 (29d ago) 29d

Ouverture des ports pour Traefik

On peut maintenant interagir avec Kubernetes, mais on ne peut toujours pas en faire grand-chose. Je suis certain que vous allez déployer des applications web sur votre cluster et c’est quand même plus cool d’y accéder depuis Internet :-p.

Par défaut, k3s installe l’IngressController traefik. Vous l’avez deviné… on va devoir ouvrir des flux !

Si vous regardez sur quels IPs/ports traefik est disponible sur votre cluster, vous remarquerez que Traefik utilise un service de type LoadBalancer, directement accessible sur l’IP privée de vos machines (10.0.0.x et 10.0.0.y dans cet exemple)

kubectl -n kube-system get svc traefik
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
traefik LoadBalancer 10.43.44.139 10.0.0.xxx,10.0.0.yyy 80:30614/TCP,443:30839/TCP 42m

Dans OCI, ça sera pratique, on va pouvoir attaquer directement le port 80/443 de nos serveurs et avoir l’IngressController au bout du fil.

$ curl http://10.0.0.xxx
404 page not found

Ne vous laissez pas tromper par l’erreur 404. Le fait qu’on nous réponde une erreur 404 prouve que traefik répond bien !

Sur les DEUX machines (control plane ET worker), on va autoriser l’accès au port 80 depuis partout :

# allow access to HTTP 80 from everywhere
$ sudo iptables -I INPUT -p tcp --dport 80 -j ACCEPT
# save rules
$ sudo netfilter-persistent save

Mais on va probablement vouloir exposer ça sur Internet et les IP privées sont… privées. On va donc créer un load balancer en frontal, ça nous permettra de diriger le trafic sur tous les noeuds du cluster, pas juste un seul (ça ferait un SPOF en plus).

Créer un Loadbalancer

Dans l’onglet Networking, on va sélectionner Loadbalancer (ici)

Suivez le wizard, choisissez un Load balancer (L7)

Puis donnez-lui un petit nom (kube-traefik-lb par exemple), laissez Public (choix par défaut), sélectionnez votre VCN et votre subnet.

Au moment de choisir les “backends”, cliquez sur “Add backends” et ajoutez vos 2 machines (c’est Kubernetes et flannel qui se chargent de rediriger les requêtes au bon endroit)

Laissez le port 80 par défaut, puisqu’on vient de vérifier que ces ports répondent bien à curl http://10.0.0.xxx (pas besoin d’utiliser le NodePort, pour ceux qui savent de quoi je parle). Laissez aussi les paramètres par défaut pour la “health check policy”, SAUF pour le code retour attendu (puisque notre traefik renvoie 404 si aucun Ingress ne matche l’“host” envoyé par la requête).

Dans la page d’après dans “configure Listener”, si vous avez un certificat TLS valide, vous pouvez l’intégrer au loadbalancer avec l’option “Load balancer managed certificate” dans le cadre “SSL certificate”. Vous pouvez aussi gérer les certificats depuis Oracle Cloud Infrastructure. Je n’ai pas exploré cette option mais c’est très standard chez les cloud providers.

Sinon, cliquez sur “HTTP”.

Une fois le LoadBalancer créé, il devrait devenir “vert” et vous pourrez récupérer son adresse IP publique pour y accéder.

Conclusion

Vous êtes arrivés jusque-là. Bravo !

Vous pouvez déployer des applications web avec des Ingress et faire pointer vos enregistrements DNS sur l’IP du LoadBalancer. Les requêtes HTTP seront correctement routées sur un des deux serveurs Kubernetes, puis vers Traefik, puis vers votre appli.

J’ai fait le test avec une image Docker personnelle (utilisée pour mon dernier talk) et ça a marché :-).

On a fait plus d’iptables que de Kubernetes mais bon c’est pas très grave 😅. Ca aura été une excuse pour tester le free tier d’Oracle et de tester un peu le fonctionnement de ce cloud provider assez peu connu en France (je trouve).

Autres blogs posts utiles

Un cluster Kubernetes gratuit pour vos labs persos ! - part 1

Mon, 24 Apr 2023 06:00:00 +0200

Cet article fait partie d’une suite d’articles sur l’installation d’un cluster Kubernetes sur le free tier d’Oracle Cloud Infrastructure :

L’avantage principal de ce tuto est qu’il est gratuit. L’inconvénient est que l’installation est relativement longue…

Le titre le plus clickbait du blog

Je me suis bien marré en écrivant ce titre “accrocheur” (pour rester poli). Pour autant, il n’est pas vraiment faux.

Évidemment, dans la vie capitaliste dans laquelle nous vivons, rien n’est jamais vraiment gratuit. Là en l’occurrence, je vais vous guider pour créer un cluster Kubernetes qui ne vous coutera rien personnellement, il sera juste payé avec nos audits Oracle(*).

En revanche, ça va nous demander pas mal de taf. On va utiliser plusieurs services d’Oracle Cloud Infrastructure, k3s, traefik, on va jouer avec le kubeconfig, … Bref, ya du boulot, et c’est même trop long pour un seul article !

(*) Pour ceux qui n’ont pas la vanne, Oracle est historiquement connue pour sa politique tarifaire assassine (vive le vendor lock !), pour sa propension à changer les règles de licensing tous les ans, et le tout associé à des audits forcés (relativement scandaleux) chez les clients pour leur soutirer toujours un peu plus de thunes. Aaaah, c’était la bonne époque.

En route vers le “free tier” de chez Oracle Cloud Infrastructure

Si je vous parle de cloud providers mondiaux américains, je suis sûr que vous allez penser AWS, Azure ou GCP. Les plus old school d’entre vous penseront peut-être à des providers comme IBM Cloud, les plus internationaux d’entre vous penseront peut-être à Alibaba cloud.

Mais qui a déjà testé Oracle Cloud Infrastructure (OCI) ? Car oui, Oracle fait du cloud, pas seulement des bases de données et des audits chez leurs clients.

C’est même un gros provider, très souvent cité dans la liste des “top 5 cloud providers”.

Note : je n’ai pas du tout été vérifié les parts de marchés, peut être qu’Alibaba fait beaucoup plus, je parle juste en termes de résultats sur un moteur de recherche.

Ca fait des années que j’hésite à tester OCI car ils ont un free tier qui jusqu’à présent était plutôt correct et qu’ils ont a priori un rapport performance/prix bien meilleur que les 4 autres “gros” cloud providers.

Depuis quelques années, ils ont aussi décidé de miser une pièce (comme d’autres) sur l’ARM… J’en dis pas plus pour l’instant.

On se crée un compte d’essai

Comme la plupart des clouds providers, on appâte le chaland avec un essai gratuit en plus de free tier. Chez OCI, c’est 300$ pour 30 jours d’essai (c’est un peu court mais il n’y a que GCP à ma connaissance qui donne plus).

En échange de cet essai gratuit, il va falloir rentrer des informations personnelles et une carte de crédit valide (comme chez tous les autres).

Oracle “garanti” cependant que tant que vous resterez sur le compte d’essai (que vous ne faites pas l’action de “mettre à niveau” votre compte), vous resterez sur un compte gratuit et vous ne serez jamais débité. Faites quand même un peu gaffe…

Une fois le compte créé

La création du compte elle-même prend un peu de temps. On peut s’y connecter au bout de quelques minutes mais tout n’est pas encore finalisé. Dans mon cas tout était vraiment opérationnel au bout d’une demi-heure environ, soyez donc un peu patients…

Petite subtilité, on vous demandera de créer un tenant aussi appelé parfois Cloud Account Name (zwindlercorp par exemple) puis de vous connecter avec un email. C’est la manière pour Oracle de gérer le multi-utilisateurs sur leur plateforme.

Une fois connecté à la console, on peut commencer à faire joujou. La première chose qu’on va devoir faire est de se placer dans un “Compartment”. Je n’ai pas creusé en détail cette fonctionnalité, pour faire simple on va se placer à la racine de notre “tenant”.

Puis, on va créer un VCN pour Virtual Cloud Networks, qui va être notre gros réseau privé virtuel dans tout notre tenant Oracle Cloud.

cloud.oracle.com/networking/vcns

J’ai utilisé le VNC Wizard, j’ai cliqué sur “Create VCN with Internet Connectivity” (l’option par défaut) et j’ai juste donné un nom “vcn1”.

Une fois que c’est terminé, on peut commencer à créer nos machines…

Ampere

Je le disais en introduction, Oracle Cloud Infrastructure a misé en partie sur des infrastructures ARM. Et pour nous donner envie de tester, à mis en place un free tier plus qu’alléchant pour un lab perso :

Each tenancy gets the first 3,000 OCPU hours and 18,000 GB hours per month for free to create Ampere A1 Compute instances using the VM.Standard.A1.Flex shape (equivalent to 4 OCPUs and 24 GB of memory). Each tenancy also gets two VM.Standard.E2.1.Micro instances for free.

Je passe sur les 2 instances E2.1.Micro (qui sont des VMs 1 cpu / 1 Go de RAM en x86 classique) pour parler plus en détail de la partie Ampere.

Oui, vous avez bien lu, on a le droit d’utiliser 4 OCPUs et 24 Go de RAM gratuitement. Et le mieux dans tout ça, c’est qu’on peut le répartir entre plusieurs machines (par tranches de 1 OCPU / 6 Go de RAM) !

Je ne sais pas vous, mais moi j’ai eu des labs avec bien moins de ressources que ça !

Compute

On va donc créer pour notre cluster Kubernetes 2 machines Ampere de 2 OCPUs et 12 Go de RAM. L’une sera notre control plane, l’autre notre worker.

Note : rien ne vous oblige à faire le même setup. Vous pouvez faire 4 machines de 1 OCPU / 6 Go de RAM, une de 1/6 et une de 3/18, etc. Note 2 : pour la petite histoire, c’est sur ce type de machine que j’ai fait la démo dans mon talk “Démystifions le comportement interne de Kubernetes” à DevoxxFR 2023 et ça a très bien marché ;-P.

cloud.oracle.com/compute/images

On prendra soin de changer l’OS (j’utilise une Ubuntu 22.04 classique, mais en vrai vous pouvez en utiliser d’autres) et la “shape” :

Dans la partie Networking, il va falloir cliquer sur “Edit” sinon la machine ne pourra pas se créer. On va affecter la machine à notre VCN qu’on vient de créer plus haut juste en cliquant sur “Edit” (les valeurs se remplissent par défaut).

Pour terminer, n’oubliez pas d’ajouter une clé SSH sans quoi vous ne pourrez pas vous connecter sur vos machines…

Je crée donc 2 machines avec ces informations, une qui s’appelle controlplane et l’autre qui s’appelle worker. Au bout de quelques minutes, les machines sont accessibles.

Récupérez et mettez de côté les IPs privées / publiques de chaques machines.

Ouverture des ports internes

Contrairement à d’autres cloud providers, les firewalls sont configurés (plutôt bien d’ailleurs) par défaut sur toutes les images OCI disponibles.

Si vous essayez d’installer Kubernetes sur une de ces machines, il est probable que l’installation échouera car les flux (même internes) seront bloqués.

On va devoir se connecter sur nos machines pour autoriser explicitement certains flux. Pour voir comment c’est configuré par défaut, vous pouvez aller voir le contenu du fichier rules.v4 :

cat /etc/iptables/rules.v4
# CLOUD_IMG: This file was created/modified by the Cloud Image build process
# iptables configuration for Oracle Cloud Infrastructure
[...]

Voici la liste des choses qu’on va devoir ouvrir :

l’accès pour 10.42.0.0/16 (CIDR des pods) et 10.43.0.1/16 (CIDR des services)
l’accès au control plane / port 6443 sur tout le LAN privé

Sur le control plane, lancez les commandes suivantes (remplacez YOUR.OWN.IP.ADDRESS par les bonnes valeurs) :

# allow flannel traffic from/to 10.42.0.0/16 (pods) and 10.43.0.0/16 (services)
sudo iptables -I INPUT -s 10.42.0.0/15 -j ACCEPT
sudo iptables -I FORWARD -o cni0 -j ACCEPT
sudo iptables -I FORWARD -o flannel.1 -j ACCEPT
sudo iptables -I FORWARD -i flannel.1 -j ACCEPT
sudo iptables -I OUTPUT -o cni0 -j ACCEPT
sudo iptables -I OUTPUT -o flannel.1 -j ACCEPT
sudo iptables -I OUTPUT -d 10.42.0.0/15 -j ACCEPT

# Allow api access to private lan
sudo iptables -I INPUT -p tcp -s 10.0.0.0/24 --dport 6443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

# save rules
sudo netfilter-persistent save

Sur le worker, lancez les mêmes commandes mais dans la partie “Allow api access to private lan”.

Ouverture des ports côté VCN

En plus de devoir configurer les firewalls côté OS, on va aussi devoir autoriser les flux internes sur le VCN. Dans la liste des VCN, cliquez sur le subnet “public”, puis sur “Default Security List for vcn1” tout en bas.

On tombe sur un tableau de tous les flux autorisés sur ce VCN (Ingress et Egress). Cliquez sur “Add Ingress Rules” pour en ajouter une nouvelle.

On va d’abord devoir explicitement ajouter des règles pour permettre à nos machines de se parler entre elles. Pour faire simple dans ce tutoriel, j’ai autorisé tout le traffic sur le lan 10.0.0.0/16.

Pour un lab, c’est largement suffisant. Dans un contexte de production, on voudra par contre explicitement autoriser les flux un à un. Vous pouvez trouver une liste des flux à ouvrir via la page de documentation de k3s.

Installation de Kubernetes

Pour aller plus vite dans ce tuto, je voulais utiliser l’outil k3sup d’Alex Ellis (aussi founder d’OpenFaaS), mais j’ai eu du mal à faire comprendre à l’outil que je voulais utiliser les IP publiques pour me connecter en SSH, et les IP privées pour les connexions vers l’API server.

Je vais donc utiliser k3s directement, en me connectant en SSH sur les machines directement.

Sur le node controlplane :

curl -sfL https://get.k3s.io | sh -

k3s devrait s’installer en quelques secondes. Récupérez le contenu du fichier /var/lib/rancher/k3s/server/node-token qui contient le token pour ajouter des nodes.

On installe ensuite le node worker :

CONTROLPLANE_PRIVATE_IP=x.x.x.x
curl -sfL https://get.k3s.io | K3S_URL=https://${CONTROLPLANE_PRIVATE_IP}:6443 K3S_TOKEN=valeur-du-fichier-node-token sh -

Au bout de quelques minutes (une seule devrait suffire, en vrai), vous devriez pouvoir commencer à accéder à votre cluster depuis le serveur controlplane

root@controlplane:~# kubectl get nodes
NAME STATUS ROLES AGE VERSION
worker Ready <none> 35m v1.26.3+k3s1
controlplane Ready control-plane,master 39m v1.26.3+k3s1

Tadaaaaa 🎉🎉

Is this the end?

En vrai, il reste encore pas mal de taf (récupérer le kubeconfig pour notre poste, ouvrir les flux pour traefik, …) pour que notre cluster soit vraiment opérationnel et l’article est déjà assez long (11000 signes)…

Ca va mériter une “part2” ultérieure ;-P.

Edit : la suite est ici