Un monde d'octets

Pour faire de son microk8s une plateforme de test fonctionnelle, il nous manque quelques éléments :

• un controleur ingress

Ingress

Traeffik est proposé en installation automatique dans microk8s

microk8S enable traeffik

A partir de la, nous pouvons accéder à notre traeffik en nodeport 8080.

Il restera encore a voir :

• un système de monitoring/observability
• un controleur mesh

Suite à une proposition de poste full remote, il m'a été donné un fiche de poste utilisant des termes informatiques de métiers que je ne connaissais pas de prime abord mais dont il me suffisait de lier le terme aux outils fréquents connus :

CSP / Cloud Service Provider

Ce qui m'a débouté ici, c'est l'acronyme CSP, alors qu'il s'agit s'implement d'un acronyme anglais : Cloud Service Provider ...

Quand on parle de CSP Capabilities, c'est donc savoir ce que founit le Cloud Provider comme possibités, niveau de qualité, fonctionnalités (cf : https://www.waferwire.com/blog/how-...)

Datalake

Il s'agit d'un stockage de donnée a structure floue (il peut s'agir de données structurées comme non structurées). Des datalake connus sont Hadoop, Amazon S3, Azure Data Lake (cf https://en.wikipedia.org/wiki/Data_...)

Depuis un certain temps déjà, il n'est plus possible d'afficher les logs "kernel ring buffer", la commande dmesg nous crachant un joli permission denied.

Pour oublier ce problème :

sudo sysctl kernel.dmesg_restrict=0

Pour oublier définitivement ce problème :

sudo vi /etc/sysctl.d/10-local.conf

et ajouter la ligne :

kernel.dmesg_restrict = 0

bien sur cela à des implications fortes, car maintenant tous les utilisateurs on accès à dmesg, ce qui dans certains cas peut révéler des informations sensibles... Mais pour vous chez vous dans votre cave, alors la ... ça vaaaaaa

pour trouver les serveurs upnp disponibles via ssdp :

sudo apt install gupnp-tools
gssdp-discover -i wlan0 --timeout=3

Pour s'affranchir du retour automatique à la ligne, vous pouvez faire dans votre shell :

setterm -linewrap off

A partir de maintenant, vos lignes n'ont plus de césure automatique, mais cela entraîne une perte de données si le terminal ne propose pas le défilement horizontal (ce qui peut-être le cas suite a une mauvaise détection de largeur induite par un empilement de type : ssh, screen, byobu, curses ...)

En attendant c'est bien pratique pour afficher des fichiers larges sans avoir un pâté illisible à l'écran, car souvent les informations les plus pertinentes sont en début de lignes (oh, simple humains que nous sommes !!)

Bien sur pour revenir en arrière :

setterm -linewrap on

Pour faire un package python, il faut créer un fichier setup.py :

import setuptools

setuptools.setup(
    name="simplanimator", # Replace with your own username
    version="0.0.2",
    author="Me First Name Last Name",
    author_email="me@tlc.com",
    description="SimplAnimator, a class to animate graph based on mathplotlib",
    url="",
    packages=setuptools.find_packages(),
    classifiers=[
        "Programming Language :: Python :: 3",
        "License :: OSI Approved :: MIT License",
        "Operating System :: OS Independent",
    ],
    python_requires='>=3.6',
)

Et nous mettons notre package dans un dossier "simplanimator" juste au même niveau que le "setup.py".

Nous pouvons ensuite installer le package avec :

sudo python3 setup.py install

ou pour une installation mono utilisateur :

python3 setup.py install --user

Un petit script pour lister les couple clef/valeurs présentes dans notre memcached en python, qui nécessitait une lib python non disponible dans pip ...

#!/usr/bin/env python3

''' 
  pip3 install 'git+git://github.com/dlrust/python-memcached-stats.git'
''' 
                                                                                                        
from memcached_stats import MemcachedStats
from pymemcache.client.base import Client

mem = MemcachedStats()
client = Client(server="localhost")

keys=[]

for key in mem.keys():
  if (not key in keys):
    result = client.get(key)
    print (key,"=>",result)
    keys.append(key)

$ telnet 127.0.0.1 11211

stats items

STAT items:4:number 1
STAT items:4:number_hot 0
STAT items:4:number_warm 0
STAT items:4:number_cold 1
STAT items:4:age_hot 0
STAT items:4:age_warm 0
STAT items:4:age 38
STAT items:4:mem_requested 164
STAT items:4:evicted 0
STAT items:4:evicted_nonzero 0
STAT items:4:evicted_time 0
STAT items:4:outofmemory 0
STAT items:4:tailrepairs 0
STAT items:4:reclaimed 0
STAT items:4:expired_unfetched 0
STAT items:4:evicted_unfetched 0
STAT items:4:evicted_active 0
STAT items:4:crawler_reclaimed 0
STAT items:4:crawler_items_checked 0
STAT items:4:lrutail_reflocked 0
STAT items:4:moves_to_cold 20
STAT items:4:moves_to_warm 0
STAT items:4:moves_within_lru 0
STAT items:4:direct_reclaims 0
STAT items:4:hits_to_hot 0
STAT items:4:hits_to_warm 0
STAT items:4:hits_to_cold 19
STAT items:4:hits_to_temp 0
END

stats cachedump 4 100

ITEM soma_key [97 b; 0 s]
END

Ca fonctionne aussi simplement que ca en telnet, mais on peut faire plus simple :

pip3 install memcached-search
memcached-search items

memcached-search est un outil d'interrogagtion en ligne de commande simple et utile pour vérifier ce qui est stocké.

Retrieve the capacity of pods by nodes :

kubectl get nodes -o json | jq '.items[].status.capacity.pods'

Retrieve IPs of all pods in all namespaces :

kubectl get pods -A -o json | jq '.items[].status.podIP'

La césure des lignes dans un docker ps m'ennuie toujours. J'aime donc reformater l'output :

docker ps --format "table {{.ID}}\t{{.Image}}\t{{.Names}}\t{{.Ports}}"

Bien sur il existe d'autres formats de sorties (comme json) permettant de "verticaliser" l'output :

docker container ls --format='{{json .}}' | jq

Ce qui est bien pratique, car ca nous donne tous les champs utilisables dans format "table". Bien sur, tout cela est moins puissant que la syntaxe go, mais c'est une autre histoire...

Pour m'autoformer sur gitlab et la partie CI, j'ai remonté mon microk8s, installé gitlab en docker, connecté mon gitlab a kubernetes et ajouté un runner en contexte kubernetes.

Il ne restait plus qu'a prendre un projet docker, et a essayer de le builder avec upload dans ma registry privée.

Les tests avec les images docker et docker-dind m'ont posé plus de problèmes qu'autre chose. Je me suis finalement rabbatu sur buildah.

Dans les problèmes rencontrés, il y'a eu le tagging, ou faute d'expérience, il a fallu que je comprenne quoi mettre dans les valeurs pour que ma registry ne rejette pas pour défaut de manifest.

Il a aussi fallu ajouter l'option de tls a la commande buildah pour qu'il n'échoue pas en se plaignant que ma registry ne supporte par https.

voici le .gitlab-ci.yml pour la partie build :

stages:
  - build

build and push to gitlab registry:

  stage: build
  image: fcadeillan/buildah

  variables:
    BUILDAH_FORMAT: "docker"
    IMAGE_NAME: "db2http"
    IMAGE_FQN: "192.168.1.30:5000/db2http"

  before_script:

  script:
    - buildah bud -t ${IMAGE_FQN}:${CI_COMMIT_REF_SLUG} .
    - buildah push --tls-verify=false docker://${IMAGE_FQN}:${CI_COMMIT_REF_SLUG}

Enfin voila une bonne chose de faite. Prochaine fois, on attaquera le déploiement sur kubernetes pour faire bonne figure !

Pour ceux qui l'ignorent, une charge excessive a souvent comme raison des processus en attente de ressource. Un "top" indique un %cpu faible, mais un %wait qui peut dépasser les 40%, et c'est rarement bon ...

Exemple de check avec mpstat :

mpstat 1

Linux 5.8.0-28-generic (teknomage) 	13/12/2020 	_x86_64_	(4 CPU)

00:10:16     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
00:10:17     all    5,68    0,00    1,08    0,54    0,00    2,70    0,00    0,00    0,00   90,00
00:10:18     all    5,43    0,00    2,45    0,27    0,00    2,17    0,00    0,00    0,00   89,67
00:10:19     all    6,49    0,00    3,24    0,00    0,00    1,89    0,00    0,00    0,00   88,38
00:10:20     all    6,20    0,00    1,89    0,00    0,00    2,96    0,00    0,00    0,00   88,95
00:10:21     all    6,09    0,00    1,94    1,94    0,00    1,39    0,00    0,00    0,00   88,64
00:10:22     all   10,78    0,00    4,58    0,00    0,00    2,70    0,00    0,00    0,00   81,94

On voir bien ici les valeurs qui nous intéressent, pour commencer à identifier le noeud dans le système :

• usr : temps passé dans du code utilisateur
• sys ; temps passé dans les appel systèmes
• iowait : temps passé à attendre du event hardware (disque dur, réseau, ...)
• idle : temps passé à ne rien faire, si c'est haut, votre pc ne travaille pas

Si la majeure partie du cpu est consommée par usr+sys, alors votre système souffre d'une surcharge cpu.

Si la majeure partie du cpu est consommée par du iowait, alors votre système attends des ressources lentes, et dans ce cas ...

avec PS

la commande PS nous indique des flags pour chaque processus courant. le flag D indique que le process est en attente d'une ressource.

watch -n 1 "(ps aux | awk '\$8 ~ /D/  { print \$0 }')"

avec iostat, si l'attente est purement de type "block"

nous pouvons voir ainsi si nous avons un disque dur qui est très sollicité et devient donc un bottleneck (vitesse cpu > vitesse dd)

iostat -x 1 3

Tracer les block dump

nous pouvons voir aussi quels process font des opération de manipulation de block

echo 1 > /proc/sys/vm/block_dump
tail -f /var/log/syslog

ne pas oublier de repasser à 0 une fois le debugging fait, car c'est couteux en espace disque

echo 0 > /proc/sys/vm/block_dump

Pour mes travaux perso, publier sur mon docker hub perso est plutot contraignant. Il était largement temps de faire une simplissime docker registry pour ces besoins ponctuels.

Lancer la registry avec le container docker fourni par le docker hub est trivial :

docker run --restart always \
           -p 5000:5000 \
           --name registry \
           registry:2

Puis pour uploader une image docker ubuntu sur notre registry :

docker pull ubuntu
docker tag ubuntu localhost:5000/ubuntu
docker push localhost:5000/ubuntu

pour eteindre son ecran a distance, il suffit de faire :

xset -display :0.0 dpms force off

mais pour savoir si il est éteint ou allumé, on fait :

xset -display :0.0 -q

Keyboard Control:
  auto repeat:  on    key click percent:  0    LED mask:  00000002
  XKB indicators:
    00: Caps Lock:   off    01: Num Lock:    on     02: Scroll Lock: off
    03: Compose:     off    04: Kana:        off    05: Sleep:       off
    06: Suspend:     off    07: Mute:        off    08: Misc:        off
    09: Mail:        off    10: Charging:    off    11: Shift Lock:  off
    12: Group 2:     off    13: Mouse Keys:  off
  auto repeat delay:  500    repeat rate:  33
  auto repeating keys:  00ffffffdffffbbf
                        fadfffefffedffff
                        9fffffffffffffff
                        fff7ffffffffffff
  bell percent:  50    bell pitch:  400    bell duration:  100
Pointer Control:
  acceleration:  2/1    threshold:  4
Screen Saver:
  prefer blanking:  yes    allow exposures:  yes
  timeout:  0    cycle:  0
Colors:
  default colormap:  0x20    BlackPixel:  0x0    WhitePixel:  0xffffff
Font Path:
  /usr/share/fonts/X11/misc,/usr/share/fonts/X11/Type1,built-ins
DPMS (Energy Star):
  Standby: 0    Suspend: 0    Off: 0
  DPMS is Enabled
  Monitor is Off

Docker n'est pas aussi étanche qu'on pourrait le penser, du moins loin d'être exempt de bugs ... cf le CVE-2019-5736. Mais en soit, ce problème d'étanchéité du container n'a d'importance qu'en cas de corruption du container.

Il faut donc ce soucier de la sécurité du container que l'on déploit, car c'est par lui que l'attache sera déclenchée.

En plus du contrôle des ports ouvert, des services actifs, des cve existant pour les logiciels installé, il existe des outils qui peuvent simplifier et surtout compléter ces audits :

Anchore & Clair est l'un de ceux-ci

Voici un article intéressant à ce sujet :

https://towardsdatascience.com/anal...

Après avoir joué avec gcloud, pour travaux kubernetes, il peut arriver qu'on ai le probleme suivant :

docker.credentials.errors.InitializationError: docker-credential-gcloud not installed or not available in PATH

En fait, il s'agit d'un reliquat de configuration présant dans .docker/config.json :

{
  "credHelpers": {
    "gcr.io": "gcloud", 
    "us.gcr.io": "gcloud", 
    "eu.gcr.io": "gcloud", 
    "asia.gcr.io": "gcloud", 
    "staging-k8s.gcr.io": "gcloud", 
    "marketplace.gcr.io": "gcloud"
  }
}

Il suffit donc de supprimer les références à gcloud, ou plus simplement détruire le fichier si il n'y a rien d'autre.

ctop permet devoir l'utilisation des containers en cpu, mem, etc.

il permet de ce faire de vérifier que vos limites positionnées sont respectées.

il peut s'installer avec apt, mais aussi tourner dans un container docker pour ne nécessiter aucune installation locale :

sudo apt install ctop

docker run --rm -ti \
  --name=ctop \
  --volume /var/run/docker.sock:/var/run/docker.sock:ro \
  quay.io/vektorlab/ctop:latest

A vous de choisir !

Ce post est la pour ce rappeler de ce paradigme permettant une nouvelle approche de la résilience d'un système, introduite par Netflix en 2015.

Pour faire simple :

Si ce n’est pas cassé, ne le répare pas.
    Bert Lance, Nation’s Business, 1977

est complétée par l'approche :

Si ce n’est pas encore cassé, essaye plus fort.
    Philosophie Chaos Engineering, 2015

Liens d’intérêts

• https://principlesofchaos.org/
• https://litmuschaos.io/
• https://chaostoolkit.org/

Si vous avez plusieurs poois sur votre cluster gke afin de segmenter vos usages pour en assurer un niveau de qualité, voici l'affinité à utiliser :

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/gke-nodepool
            operator: In
            values: 
            - pool-worker-nlp
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent

En splitant un log au format yaml, pour couper au "---" séparateur, j'ai atteint le "too many open files".

La solution est simple. Fermer le flux après y avoir écrit :

awk '{if (/---/) cpt++; 
          print $0 >> cpt+".txt"; 
          close (cpt+".txt")}'

Ce script python fait une copie d'un dossier dans le meme filesystem au moyens de plink ;

#!/usr/bin/env python3

import os, sys

try:
  source=sys.argv[1]
  dest=sys.argv[2]
except:
  pass


try: os.mkdir(dest)
except: pass

for root, dirs, files in os.walk(source, topdown=True):

  for name in dirs:
    subpath="/".join(os.path.join(root,name).split("/")[1:])
    try: os.mkdir(os.path.join(dest,subpath))
    except: pass
      

  for name in files:
    subpath="/".join(os.path.join(root,name).split("/")[1:])
    os.link(os.path.join(source,subpath),os.path.join(dest,subpath))

Pourquoi ce script ? c'est parce que maintenant, si vous modifiez la copie, l'original lui ne bougera pas ! ce qui avec un script copiant un serveur distant avec rsync, nous donnera une parfaite copie différentielle entre les deux backups !

Certains PV sont marqués comme "intuables", leur yaml contenant :

  finalizers:
  - kubernetes.io/pv-protection

Rien qu'un bon coup de hache (jq modifie le json à la volée en vue d'une application direct changeant la donne) ne puisse régler :

for f in `kubectl get pv,pvc | grep <volume> | awk '{print $1}' ` 
do 
  kubectl get $f -o=json | jq '.metadata.finalizers = null' | kubectl apply -f - 
  kubectl delete $f ; 
done

Création d'un volume

gcloud compute disks create nextcloud-app-static-pv --zone europe-west1-b --size=500Gb 
gcloud compute disks create nextcloud-db-static-pv --zone europe-west1-b --size=10Gb 

Attacher une instance

gcloud compute instances attach-disk  gke-integration-default-pool-ea501286-hpww --disk nextcloud-app-static-pv 

Initialisation du disque

gcloud compute ssh [INSTANCE_NAME]
lsblk
mkfs.ext4 /dev/sdXXXX

Pour utiliser occ dans une version containerisée de nextcloud, il faut passer en tant que www-data.

Seulement voila, la ou docker peut faire un run-as avec l'option "-u" (qu'occ nous rapelle gentilement), pour kube c'est une autre histoire.

En fait, la seule solution c'est d'utiliser sudo, sauf que bien sur, le container est fourni sans sudo, avec un compte www-data que l 'on ne peut pas utiliser avec su, car le compte est désactivé.

Bien sur, il est désactivé comme souvent, avec l'utilisation simple d'un shell ne permettant pas l'interaction.

Pour pouvoir utiliser occ, il faut simplement contourner ce shell comme suit :

su www-data -s /bin/bash

et voila nous pouvons utiliser occ en ligne de commande pour administrer notre nextcloud

php occ app:list 

ce qui permettra de scripter les installation de plugins, et donc de les automatiser avec kubernetes !

Et pour rigoler, en one-shot :

kubectl exec nextcloud-app-686d746495-nzj8s -- bash  -c 'su www-data -s /bin/bash -c "php occ app:list"'