Kubespray : installation d’un cluster K8S se rapprochant de la production

Installer kubernetes on premise est un petit défi même si certaines solutions sont plus simples que d’autres. J’ai pu tester différentes options comme kubadm, rancher ou en core kubespray mais jamais « the hard way ». Cette dernière méthode est certainement la meilleure pour mieux appréhender la constitution d’un cluster. Certes, cette méthode est formatrice mais peut effrayer notamment faire peur si on veut installer un cluster kubernetes pour de la production

Je vous propose de découvrir une méthode intermédiaire mais d’y ajouter le nécessaire pour rendre votre cluster hautement disponible. Et vous allez voir que contrairement à ce que l’on pense ce n’est pas si compliqué. Je vous invite après cette installation de prendre du recul et d’identifier les points critiques pour être bien à l’aise avec ces éléments. Car le jour où votre cluster kube dysfonctionne en production et on premise, vous pouvez transpirer pas mal pour débuguer car généralement vous n’avez pas mis qu’une seule application dessus.

Tout le code ci-dessous est présent dans mon dépôt officiel.

Mais je vous invite à découvrir les vidéos dans cette playlist youtube :

De quoi avons nous besoin côté machines virtuelles ?

Eh oui on veut tester un environnement de production mais rien ne vous empêches de vous faire la main sur votre laptop ou de simples machines virtuelles. Personnellement, j’utilise souvent virtualbox et je fais le provisioning de manière automatisé avec vagrant. Le Vagrantfile est donc ce qui va le mieux décrire notre infrastructure. J’ai volontairement évité de factoriser les boucles de manière à rendre cela plus lisisble.

Notre infrastructure sera composée :

  • 1 machine de déploiement pour jouer kubespray (ansible) on va pas salir notre laptop non plus et en prod on ne déploie pas de son laptop.
  • 2 haproxy : ils serviront pour loadbalaner l’api kubernetes pour les commandes kubectl vers nos master (port 6443) et également pour loadblancer sur les noeuds worker les flux http/https (80/443)
  • 2 masters : il vaudrait mieux 3 mais notre but est de faire de simples tests tout de même (en ajoute run n’est juste que rajouter une ligne dans le ansible)
  • 1 node : notre objectif n’est pas d’héberger mais de tester un cluster kube et son environnement haute disponibilité.

Ce qui donne :

Vagrant.configure(2) do |config|
  common = <<-SHELL
  if ! grep -q deploykub /etc/hosts; then  sudo echo "192.168.7.120     kdeploykub" >> /etc/hosts ;fi
  if ! grep -q node01 /etc/hosts; then  sudo echo "192.168.7.121     kmaster01" >> /etc/hosts ;fi
  if ! grep -q node02 /etc/hosts; then  sudo echo "192.168.7.122     kmaster02" >> /etc/hosts ;fi
  if ! grep -q node03 /etc/hosts; then  sudo echo "192.168.7.123     knode01" >> /etc/hosts ;fi
  if ! grep -q node04 /etc/hosts; then  sudo echo "192.168.7.124     haproxy01" >> /etc/hosts ;fi
  if ! grep -q node05 /etc/hosts; then  sudo echo "192.168.7.125     haproxy02" >> /etc/hosts ;fi
  sudo yum -y install vim tree net-tools telnet git python3-pip sshpass
  sudo setsebool -P haproxy_connect_any=1
  sudo echo "autocmd filetype yaml setlocal ai ts=2 sw=2 et" > /home/vagrant/.vimrc
  sed -i 's/ChallengeResponseAuthentication no/ChallengeResponseAuthentication yes/g' /etc/ssh/sshd_config
  sudo systemctl restart sshd
  SHELL
  

	config.vm.box = "centos/7"
	config.vm.box_url = "centos/7"

	config.vm.define "kdeploykub" do |kdeploykub|
		kdeploykub.vm.hostname = "kdeploykub"
		kdeploykub.vm.network "private_network", ip: "192.168.7.120"
		kdeploykub.vm.provider "virtualbox" do |v|
			v.customize [ "modifyvm", :id, "--cpus", "1" ]
			v.customize [ "modifyvm", :id, "--memory", "512" ]
			v.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
      			v.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
			v.customize ["modifyvm", :id, "--name", "kdeploykub"]
		end
		config.vm.provision :shell, :inline => common
	end
	config.vm.define "kmaster01" do |kmaster01|
		kmaster01.vm.hostname = "kmaster01"
		kmaster01.vm.network "private_network", ip: "192.168.7.121"
		kmaster01.vm.provider "virtualbox" do |v|
			v.customize [ "modifyvm", :id, "--cpus", "2" ]
			v.customize [ "modifyvm", :id, "--memory", "2048" ]
			v.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
      			v.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
			v.customize ["modifyvm", :id, "--name", "kmaster01"]
		end
		config.vm.provision :shell, :inline => common
	end
	config.vm.define "kmaster02" do |kmaster02|
		kmaster02.vm.hostname = "kmaster02"
		kmaster02.vm.network "private_network", ip: "192.168.7.122"
		kmaster02.vm.provider "virtualbox" do |v|
			v.customize [ "modifyvm", :id, "--cpus", "2" ]
			v.customize [ "modifyvm", :id, "--memory", "2048" ]
			v.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
      			v.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
			v.customize ["modifyvm", :id, "--name", "kmaster02"]
		end
		config.vm.provision :shell, :inline => common
	end
	config.vm.define "knode01" do |knode01|
		knode01.vm.hostname = "knode01"
		knode01.vm.network "private_network", ip: "192.168.7.123"
		knode01.vm.provider "virtualbox" do |v|
			v.customize [ "modifyvm", :id, "--cpus", "2" ]
			v.customize [ "modifyvm", :id, "--memory", "2048" ]
			v.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
      			v.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
			v.customize ["modifyvm", :id, "--name", "knode01"]
		end
		config.vm.provision :shell, :inline => common
	end
	config.vm.define "haproxy01" do |haproxy01|
		haproxy01.vm.hostname = "haproxy01"
		haproxy01.vm.network "private_network", ip: "192.168.7.124"
		haproxy01.vm.provider "virtualbox" do |v|
			v.customize [ "modifyvm", :id, "--cpus", "1" ]
			v.customize [ "modifyvm", :id, "--memory", "512" ]
			v.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
      			v.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
			v.customize ["modifyvm", :id, "--name", "haproxy01"]
		end
		config.vm.provision :shell, :inline => common
	end
	config.vm.define "haproxy02" do |haproxy02|
		haproxy02.vm.hostname = "haproxy02"
		haproxy02.vm.network "private_network", ip: "192.168.7.125"
		haproxy02.vm.provider "virtualbox" do |v|
			v.customize [ "modifyvm", :id, "--cpus", "1" ]
			v.customize [ "modifyvm", :id, "--memory", "512" ]
			v.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
      			v.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
			v.customize ["modifyvm", :id, "--name", "haproxy02"]
		end
		config.vm.provision :shell, :inline => common
	end

end

Ou encore ce Vagrantfile

Commençons par le loadbalancer externe haproxy et sa vip gérée par keepalived

Attention avant de lancer le ansible kubespray, il est nécessaire que votre haproxy et votre VIP soient mis en place.

Donc première chose on installe les deux haproxy et keepalived :

sudo apt install - y haproxy keepalived

et ensuite on édite la configuration de haproxy

global
    log         127.0.0.1 local2

    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon
    stats socket /var/lib/haproxy/stats

defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000

listen stats
    bind *:9000
    stats enable
    stats uri /stats
    stats refresh 2s
    stats auth xavki:password

listen kubernetes-apiserver-https
  bind *:6443
  mode tcp
  option log-health-checks
  timeout client 3h
  timeout server 3h
  server master1 192.168.7.121:6443 check check-ssl verify none inter 10000
  server master2 192.168.7.122:6443 check check-ssl verify none inter 10000
  balance roundrobin

Bien sûr derrière je vous laisse reload le service systemd de haproxy.

Ensuite ajoutons la configuration de keepalived :

vrrp_script reload_haproxy {
    script "/usr/bin/killall -0 haproxy"
    interval 1
}

vrrp_instance VI_1 {
   virtual_router_id 100
   state MASTER
   priority 100

   # interval de check
   advert_int 1

   # interface de synchro entre les LB
   lvs_sync_daemon_interface eth1
   interface eth1

   # authentification entre les 2 machines LB
   authentication {
    auth_type PASS
    auth_pass secret
   }

   # vip
   virtual_ipaddress {
    192.168.7.130/32 brd 192.168.7.255 scope global
   }

   track_script {
     reload_haproxy
   }

}

Dans cette configuration on utilise une VIP qui switchera en fonction du service haproxy et du fait qu’il soit fonctionnel au vue de systemd ou non. Cette VIP est la :

192.168.7.130

Par défaut cette VIP sera portée par la machine haproxy1. Si celui-ci tombe cette adresse va être installée sur haproxy2 grâce à keepalived.

Vérifiez que les deux services (haproxy et keepalived) soient bien démarrés sur les 2 machines haproxy. Activez le redémarrage au reboot avec le systemctl enable.

Maintenant configurons kubespray

Kubespray c’est du ansible. donc première chose vous devez l’installer sur la machine de déploiement et installer également pip :

sudo apt install ansible python3-pip

Ensuite clonez le dépôt de kubespray :

git clone https://github.com/kubernetes-sigs/kubespray

rendez-vous dans le nouveau répertoire puis :

sudo pip3 install -r requirements.txt

Ensuite on prépare le ansible on va recopier le modéèle d’inventaire :

cp -rfp inventory/sample inventory/mycluster

Puis on modifie cet inventory :

# ## Configure 'ip' variable to bind kubernetes services on a
# ## different ip than the default iface
# ## We should set etcd_member_name for etcd cluster. The node that is not a etcd member do not need to set the value, or can set the empty string value.
[all]
kmaster01 ansible_host=192.168.7.121  ip=192.168.7.121 etcd_member_name=etcd1
kmaster02 ansible_host=192.168.7.122  ip=192.168.7.122 etcd_member_name=etcd2
knode01 ansible_host=192.168.7.123  ip=192.168.7.123 etcd_member_name=etcd3

# ## configure a bastion host if your nodes are not directly reachable
# bastion ansible_host=x.x.x.x ansible_user=some_user

[kube-master]
kmaster01
kmaster02
[etcd]
kmaster01
kmaster02
knode01

[kube-node]
knode01

[calico-rr]

[k8s-cluster:children]
kube-master
kube-node
calico-rr

On y a donc déclaré nos nodes master et notre worker.

Particularité ETCD

Particularité pour notre test, nous allons faire ce qu’il ne faut pas faire c’est à dire héberger les services etcd sur les master et surtout sur 1 worker. Pourquoi cela ? Etcd nécessite un nombre impair de noeuds pour son bon fonctionnement. Donc on pourrait en avoir 1 ou 3. Mais si on veut faire des tests de coupures de noeuds il est préférable d’en avoir 3. J’ai donc salement choisi d’en ajouter un sur le worker.

En production il serait recommandé d’externaliser les etcd et ne pas les avoir au sein des machines kubernetes (plus y ajouter des backups etc).

Dernière configuration ansible

Maintenant il nous faut éditer le fichier du group all :

vim inventory/mykub/group_vars/all/all.yml

comme en modifiant ces lignes

## External LB example config
apiserver_loadbalancer_domain_name: "elb.kub"
loadbalancer_apiserver:
  address: 192.168.7.130
  port: 6443

On vient donc de préciser que la VIP est notre point d’entrée du loadbalancer et également que votre cluster répondra sur le nom de domaine elb.kub (vous pourrez modifier votre /etc/hosts).

Maintenant c’est partie on peut jouer notre ansible en tant que user vagrant et on utilisera le password « vagrant »… un standard sur vagrant.

ansible-playbook -i inventory/my-cluster/inventory.ini -u vagrant -k -b cluster.yml

Attendez plusieurs dizaines de minutes suivant votre connexion et le nombre de machines et votre cluster sera up à la fin.

Première connexion avec kubectl

Dernière tâche pour accéder à notre cluster, il nous faut récupérer le certificat du compte d’administrateur de notre cluster kubernetes.

Copiez sur un des master le fichier

cat /etc/kubernetes/admin.conf

Puis créez et collez le contenu sur la machine devant accéder au cluster :

mkdir -p ~/.kube
vim ~/.kube/config

Enfin installons kubectl sur cette même machine :

sudo apt-get update && sudo apt-get install -y apt-transport-https
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubectl

Maintenant testons notre cluster :

kubectl cluster-info
kubectl get nodes

Test de la haute disponibilité

Si tout est bien fonctionnel…

Coupez un haproxy soit en coupant le service avec un systemctl stop soit en arrêtant plus ou moins brutalement la machine.

Testez à nouveau vos commandes kubectl.

Ensuite coupez un master et procédez au même test.

Alors ça marche ?

Je vous invite à découvrir la playlist complète pour découvrir kubernetes et d’autres outils liés ici.

Tutorials pour débuter avec Kubernetes

Suivre les technologies du moment, c’est souvent le but recherché par tous les sysadmin et devops. Et cela n’est pas facile avec la démultiplication des technologies de puis l’arrivée du cloud, des conteneurs et de l’infrastructure as code. Une évolution inévitable à l’heure de l’industrialisation de l’informatique, secteur encore jeune qui a besoin d’évoluer.

Kubernetes est pleinement dans cette mouvance. D’ailleurs, le nombre de technologies ou d’outils rattachés à celui est presque affolant. Tous les jours de nouveaux outils, régulièrement de nouveaux concepts émergent également. Bref on en a jamais fini avec kubernetes. D’ailleurs l’une des forces d’un bon devops, c’est de savoir aussi attendre et faire le bon choix parmi cette forêt d’outils qui demain n’existeront plus pour certains.

Apprendre par le bon bout…

K8S pour les intimes commence déjà par docker et les principes de conteneurisation. Je vous invite à découvrir docker via la chaine xavki si vous le souhaitez. Certes kubernetes tente de se détacher de ce « conteneur runtime » mais néanmoins pour apprendre se focaliser sur docker est plutôt une bonne approche.

Mais k8s se comprend avant de s’apprendre avec de nombreux concepts et définitions. Il faut imaginer déjà que k8s est un orchestrateur de conteneurs mais c’est aussi une grosse couche logique sur les conteneurs, leurs réseaux, le stockage et le dns qui va avec.

Dans cette introduction, si vous avez du mal à imaginer kubernetes, je vous propose de vous le présenter avec simplicité.

Kubernetes vient d’ailleurs du grec et signifie timonier. On peut le comprendre car il est à la tête de ce magistral porte conteneurs.

Avec kub vous allez pouvoir bénéficier de nombreuses fonctions avancées et rares, que ne fournissent pas forcément les autres orchestrateurs de conteneurs :

  • autoguérisson
  • autoscaling
  • versionning
  • rolling update
  • sécurisation des communication entre les conteneurs par différentes couches
  • gestion de la persistence de la donnée…

Mais attention ces grands pouvoirs nécessitent une grande responsabilité comme on dit. La responsabilité de celui qui manage le paquebot. Le moindre grain de sable dans cette horlogerie et c’est le trou noir compte tenu du rôle central de l’outil. Courage donc aux sysadmins et aux devops face à ce challenge.

C’est aussi pour cela que beaucoup de choix s’orientent vers des solutions plus ou moins managés :

  • les solutions cloud : GKE, EKS…
  • les managers : rancher…

Bref c’est une aventure et on peut même simplifier en indiquant que c’est un vrai outil de virtualisation avec les responsabilités qui vont avec (et les ressources et le temps).

On ne va pas vers kubernetes pour se faire plaisir, il faut y trouver un réel intérêt sur de nombreux facteurs. On ne le fait pas pour faire comme les autres ou parce que c’est la techno du moment.

De nouvelles notions et définitions dans kubernetes

Kubernetes fait partie des technologies embarquant le plus de concepts je trouve. Intellectuellement c’est très intéressant mais c’est aussi une charge.

En voici quelques unes :

Le Pod

Inévitable, il peut regrouper un ou plusieurs conteneurs. C’est la couche logique par excellence qui va permettre une total abstraction avec l’échelon inférieur le conteneur.

Le pod contient les applicatifs, il peut être plus ou moins éphémères suivant sont types. Vous pouvez associer avec lui un applicatif et une tâche ponctuelle nécessaire pour son installation. Il peut être scallé up ou down pour soutenir la charge etc…

Les services

On pourrait les rapprocher à l’exposition des pods mais en même temps il joue une sorte de fonction de dns. L’idée est de sécuriser et permettre l’accès aux pods ayant la même fonction.

Avec eux vous pourrez en quelque sorte exposer vos conteneurs ou à l’opposé les barricader. Si les pods d’un même applicatif sont distribués sur différents noeuds, il aura la charge de fournir comment accéder à ces pods (ip port…). Il permet également de faire du dns au sein du cluster kub.

Le replicaset

Résumons-le simplement à la gestion du nombre de pods.

Le deployment

Un autre échelon très important qui englobe les replicasets et les pods. Il permet notamment de gérer la santé des pods et leur scaling suivant certaines règles. Un deployment va permettre de créer des pods suivant un template de pods. Idéal pour l’instanciation.

Les statefulsets

On peut les résumer à des deployments avec les mêmes fonctions auxquels on ajouter des facilités pour gérer la persistence de la data qui est attachée aux pods. Idéal pour les bases de données essentiellement.

Bon courage à tous mais le plaisir est au rendez-vous si vous ne brûlez pas les étapes.

Débuter avec Prometheus et se former

Le monitoring est un domaine qui existe depuis de nombreuses années pour gérer les infrastructures. Il existait avant le web mais son intérêt c’est accru d’année en année. La tolérance aux pannes étant devenue de plus en plus faible, les outils de monitoring ont évolué également avec le temps.

L’arrivée des infrastructure à base de microservices et la nécessaité de baser le monitoring sur de plus en plus d’éléments « métiers » a aussi joué ces dernières années. Si le monitoring système était bien présent auparavant, la partie applicative est devenu un enjeu important pour toute société ayant le moindre site web ou même fournissant des services en interne.

Parfois, le monitoring système est même réduit au minimum au bénéfice du service rendu final.

Vous pouvez retrouver mes prises de notes sur Prometheus en plus des vidéos de la chaine sur ce dépôt gitlab.

Prometheus et Grafana, la stack du moment

La collecte et la mise en valeur de métriques passent souvent par la combinaison de plusieurs outils. Je vous propose de découvrir aujourd’hui une partie de la stack prometheus/grafana qui est l’une des plus à la mode en ce moment.

Pourquoi ? en grande partie par sa simplicité de mise en place et son déploiement. Prometheus constitue la base de données (timeseries). Il stocke les données sur de courtes périodes (son point faible reste la rétention sur des volumes importants). Attention, il reste très performant sur de longues périodes si vous ne collectez pas trop de métriques.

Sa force ? être capable d’aller chercher lui-même l’information sur les serveurs. Alors que de nombreux autres outils fonctionnent avec des agents qui envoient l’information vers la base centralisée, Prometheus va chercher l’information.

Attention, néanmoins, vous devez mettre en place ce que l’on appelle des exporters. Il s’agit de petits binaires, souvent développés en GO (mais vous pouvez aussi développer el votre en bash ou en python). Ces derniers affichent les informations sur une route à savoir un port et un path de la machine (par défaut on utilise couramment la route /mettrics). On parle là des données où les outils ne mettent pas déjà à disposition une route pour prometheus.

Car de nombreux outils mettent à dispositions des options pour mettre en place cette route. Les données, dans tous les cas, sont affichées au format openmetrics. Un standard, facile à scraper et à utiliser.

Prometheus est aussi souvent utiliser pour ses capacités d’autodiscovery notamment dans kubernetes ou docker mais pas seulement (consul, aws, dns…).

Comment installer Prometheus ?

Bien sûr vous pouvez retrouver la documentation de prometheus ici. Cette timeseries database est tellement courante que de nombreuses distributions vous la fournissent dans les dépôts standards. Par exemple sur les OS à base de Debian :

sudo apt-get install prometheus

Sinon, bien sûr, vous pouvez l’installer facilement avec l’aide de docker pour la lancer sous forme de conteneur :

docker run -d --name prometheus \
-v $PWD/etc/:/etc/prometheus/ \
 -v $PWD/data/:/prometheus/ \
-p 9090:9090 quay.io/prometheus/prometheus:v2.0.0

Attention néanmoins à ne pas oublier qu’il s’agit d’une application stateful et que du coup vous devrez stocker des éléments en dehors du conteneur en montant un volume. Ainsi comme dans l’exemple précédent, je vous invite à monter un volume pour la configuration et un autre pour les datas. Stocker sa configuration en dehors du conteneur vous permettra de facilement relancer un conteneur similaire avec les mêmes options.

Quelques défintions pour cette TSDB particulière

Comme tout outil, Prometheus dispose de son propre langage et ses propres notions et définitions.

Sa configuration est stockée dans un fichier (par défaut prometheus.yml) au format yaml.

./prometheus --config.file=prometheus.yml

Dans ce fichier de configuration on retrouver :

  • Une partie « global » qui définit des settings par défaut par exemple :
    • scrape_interval : fréquence de collecte des métriques
    • evaluation_interval : fréquence de check des alertes
    • scrape_timeout : durée d’attente des métriques (temps de réponse de la route)
  • rule files :volet relatif à la configuration des alertes
  • scrape config : éléments relatifs aux routes mise à disposition de prometheus :
    • dynamiques ou non
    • ip/url et port
    • nom du job de scrape

Et toutes les données sont donc exportées au format openmetrics :

up{instance="192.168.62.3:9100",job="node_exporter",service="myapp"} 1

Dans cet exemple, « up » est une métrique (notamment par défaut la route prometheus), 1 sa valeur.

On découvre également ce que l’on appelle des labels comme par exemple : instance, job, service. Mais bien sûr vous pouvez aussi créer vos propres labels.

L’outil n’est pas une simple database car il récupère lui-même ses informations et met également à votre disposition une interface graphique. Par défaut, affichée sur le port 9090, elle affiche :

  • la configuration pris en compte sur le moment
  • les routes collectées
  • la possibilié de requêter les données en utilisant le langage PromQL (prometheus query language)
  • la possibilité de réaliser des graphiques (un peu rudimentaires que l’on remplacera souvent par grafana).

Node Exporter : le plus courant

On l’a dit, notre TSDB va chercher elle même ses métriques. Soit sur des outils intégrés aux applicatifs soit par le biais d’exporter. Ces outils tournent au niveau local, collecte la données et l’expose sur un port et une route (souvent /metrics par défaut).

Node exporter est l’un des plus commun. en effet, il permet de collecter des informations de bases sur le système : les disques, leurs volumes, le réseau, les process…

Pour l’installer vous devez faire votre choix :

  • par un paquet de votre distribution
  • par un conteneur docker spécifique
  • par le binaire.

Ainsi sous debian vous pouvez l’installer avec :

sudo apt-get install prometheus-node-exporter

Avec docker :

docker run -d \
  --net="host" \
  --pid="host" \
  -v "/:/host:ro,rslave" \
  -p 9100:9100 \
  --name node_exporter \
  quay.io/prometheus/node-exporter \
  --path.rootfs=/host

Et pour le faire avec le binairere source :

  • récupérez le binaire et préparez les répertoires et user
sudo useradd -rs /bin/false node_exporter
https://prometheus.io/download/#node_exporter
wget https://github.com/prometheus/node_exporter/releases/download/v0.18.1/node_exporter-0.18.1.linux-amd64.tar.gz
tar -xvzf node_exporter-0.18.1.linux-amd64.tar.gz
mv node_exporter-0.18.1.linux-amd64/node_exporter /usr/local/bin/
chown node_exporter:node_exporter /usr/local/bin/node_exporter
  • créez le service systemd pour lancer le processus et le gérer
cat /etc/systemd/system/node-exporter.service
[Unit]
Description=Node Exporter
After=network-online.target
[Service]
User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/usr/local/bin/node_exporter
[Install]
WantedBy=multi-user.target
  • puis activez le service systemd
systemctl daemon-reload
systemctl enable node_exporter
systemctl start node_exporter

Maintenant vous disposez de la route <ip>:9100/metrics sur la machine sur laquelle vous avez installé node exporter.

Il ne vous reste plus qu’à dire à prometheus de venir récupérer cette source d’informations. Bien sûr la machine prometheus doit pouvoir accéder à la route de node exporter. Ajoutez alors à votre configuration prometheus les lignes suivantes :

  - job_name: node-exporter
    static_configs:
      - targets: ['l<ip>:9100']

Labels et Filtres

Les labels et les filtres sont le quotidien de la personne qui utilise prometheus à travers les requêtes PromQL.

Les labels sont assimilables à des tags. C’est à dire une information que l’on va ajouter au fur et à mesure des scrape pour nous aider à isoler certaines données et les travailler plus facilement.

Ainsi, pour un scrape donnée (appelé aussi job), vous allez pouvoir ajouter un label nommé « environnement » :

  - job_name: node_exporter
      static_configs:
      - targets: [ '192.168.1.1:9100' ]
        labels:
          environnement: developpement

Dans le cas, d’utilisation d’autodiscovery, Prometheus autodécouvre des instances à monitorer et leurs informations (aws ec2 on retrouve les tags etc, les noms de services de consul etc). Et vous allez pouvoir ajouter ces informations complémentaires du discovery à votre liste de labels en utilisant le relabel.

scrape_configs:
  - job_name: Consul
    consul_sd_configs:
      - server: '192.168.57.10:8500'
        datacenter: 'mydc'
    relabel_configs:
      - source_labels: [__meta_consul_service]
        target_label: job

Dans cet exemple, l’information nom de service de consul vient compléter le label nommé « job ».

Les filtres permettent d’affiner les requêtes promql et limiter les résultats. Par exemple pour ne prendre en compte que le device eth0 :

node_network_receive_bytes_total{device="eth0"}

Le filtering se fait donc dans les labels mentionnés entre les accolades et la valeur mentionnées.

On peut également utiliser les regex pour plus de fléxibilités :

node_network_receive_bytes_total{device=~"eth.+"}
node_network_receive_bytes_total{device=~"eth0|lo"}

Voici donc la fin de ces premiers pas avec prometheus. Totu devops doit avoir quelques notions dans ce domaine. Je vous propose de retrouver les tutorials prometheus ici.

Top5 des vidéos devops en août 2020 !!!

La chaine youtube xavki marche bien et c’est surtout grâce à vous. Je n’ai pas trop chomé cet été finalement moi qui pensais faire une pause. Et comme je suis un addict dès que j’ai quelque chose qui me branche en finalement je n’aurais pas fait de pause.

Mon plaisir c’est de vous voir venir et revenir sur cette chaine. Et pour cela vous proposer du contenu intéressant. J’évite de faire le buzz si ce n’est de prendre des technologies à la mode dans le monde du devops.

Les dernières technologies auront été : kvm, traefik, ELK, terraform, prometheus et grafana… et j’en ai pas fini avec elles.

Alors ce top 10 de la chaine xavki ? car je suis bien incapable de dresser un top 10 à l’échelle du web il y a tellement de choix et de bons contenus.

Voici donc les vidéos les plus consultées pour le mois d’août et je vous en dis mon ressenti.

1. Docker : Premier Pas

C’est la vidéo la plus vu mais pour autant j’en suis d’autant plus déçu. Paradoxal non ? en effet, elle fait partie des premières vidéos et son son est très mauvais. Mon approche pédagogique n’est pas encore là non plus . Alors pourquoi elle marche ? docker est recherché et les tutorials en français introduisant cette technologie n’était pas si courante à l’époque. Du coup elle s’est faite sa place avec ses likes.

2. Traefik, l’introduction

Autant l’introduction à docker m’a pas forcément apporté un énorme plaisir, autant que ce genre de vidéo marche me fait plaisir. Pourquoi ? une technologie française qui marche fort en ce moment, un besoin d’en parler et le réelle sentiment que vous recherchez ce genre d’informations.

Traefik est une technologie que j’adore en ce moment pour son dynamisme et ce qu’il l’entoure. D’ailleurs je crois que je suis traefik ambassador même si je n’en ai pas réellement le niveau.

3. Kubernetes, présentation des tutorials de la chaine

Cette playlist fait partie de mes tops formations. Je peux réellement avoir le sentiment de vous faire converger vers des niveaux un peu plus pointus à chauqe fois et c’est quelque chose que j’apprécie. Bien sûr Kubernetes est à la mode et ça aide mais présenter la simple liste des vidéos à venir n’est pas forcément quelque chose de recherché. Mais c’est déjà un pas vers la formation. Comprendre et découvrir un plan de formation c’ets déjà se former à mon sens.

4. Gitlab, oui c’est recherché

Dans cette vidéo j’ai tenté de survoler et présenter les opportunités apportées par Gitlab. Un formidable outil qui a tendance à créer une forte dépendance. Petite société qui a su se faire une place parmi les très grand parmi les sociétés côtées boursières américaines. La petite société a bien évoluée autour de l’automatisation du déploiement de votre code applicatif mais pas forcément. Ils ont su intégré des technos tendances et inévitables comme : grafana, terraform, kubernetes???

5. Jenkins peut être ce qui me représente le plus…

Une vidéo simple, un peu sans prétention qui vous présente jenkins. Jenkins est un acteur historique dans le domaine du scheduling. Malgré son ancienneté, il est encore présent parmis les leaders. Et surtout sa communauté abondante rend cet outil ultra-polyvalent dans des domaines variés : déploiement, datas, infrastructure…

J’aime vraiment beaucoup ce côté polyvalent et discret mais toujours présent ce qui en démontre sa robustesse et son efficacité.

A vous de me dire à travers les commentaires dans les vidéos, les pouces bleus ou rouges, ce que vous pensez de tout cela.

Même si j’ai des regrets sur les vidéos réalisées au début de la chaine xavki, il faut l’accepter. On vient d’où l’on vient et l’on évolue. D’ailleurs il me semble plus intéressant d’évoluer et de comprendre ce process d’évolution que de déjà tout connaître sans évoluer.

Allé je vous laisse apprécier ou pas tout cela. Vous abonner ou non… voir même devenir membre VIP. A vous de voir appréciez, votre liberté de choix.