Un monde d'octets

kubectl get events --sort-by='.metadata.creationTimestamp' -A

Cela ce fait en injectant le yaml suivant :

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    k8s-app: prometheus-service-monitor
  name: prometheus-service-monitor
  namespace: infra-kyverno
spec:
  endpoints:
  - interval: 30s
    port: metrics
    scheme: http
  selector:
    matchLabel:
      app.kubernetes.io/part-of: kyverno

celu-ci, éant dans le même namespace que kyverno, précise les modalités de scrapping et le selecteur pourles pods conernés

Ajouter ou supprimer un label

kubectl label ns infra-pvalois --overwrite "save-by-velero=true"
kubectl label ns infra-pvalois --overwrite "save-by-velero-"

Chercher qui a, ou n'as pas un label

kubectl get ns --selector='save-by-velero=true'
kubectl get ns --selector='save-by-velero!=true'

oc get secret vault-keys -n openshift-infra -o yaml | yq '.data.key1 | @base64d , .data.key2 | @base64d , .data.key3 | @base64d , .data.root_token | @base64d'

Voici ce que ChatGPT répond :

Si votre PVC est utilisé sur un serveur Ceph RBD (RADOS Block Device), vous pouvez effectuer un fsck de la même manière que décrit précédemment en utilisant la commande rados -p <nom-du-pool> check <nom-de-l'objet>.

Voici les étapes à suivre pour effectuer un fsck sur un PVC utilisé sur un serveur Ceph RBD :

    Vérifiez que le pod associé au PVC est en état "Terminé" ou "En cours d'exécution".

    Utilisez la commande kubectl describe pv <nom-du-pvc> pour obtenir les informations du volume persistant.

    À partir des informations précédentes, récupérez le nom de l'image RBD correspondant au volume persistant.

    Utilisez la commande rbd ls <nom-du-pool> pour lister les images RBD disponibles dans le pool Ceph.

    Exécutez la commande rados -p <nom-du-pool> check <nom-de-l'objet> pour vérifier la cohérence du système de fichiers de l'image RBD correspondante. Remplacez <nom-du-pool> par le nom du pool Ceph utilisé par le PVC et <nom-de-l'objet> par le nom de l'image RBD correspondante.

    Attendez que la vérification soit terminée. Le temps nécessaire dépend de la taille de l'image et de l'état de cohérence du système de fichiers.

Notez que le fsck peut être un processus long et potentiellement destructeur pour les données, il est donc recommandé de sauvegarder les données importantes avant de l'exécuter. De plus, si vous détectez des erreurs lors de la vérification, il est recommandé de contacter l'administrateur de votre cluster Ceph pour obtenir de l'aide sur la façon de les 

Celle-la, parait intéressante, mais j'ai pas encore les clef pour la tester ....

Do so :

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

https://killer.sh/

Deployment :

mettre en ligne un pod (servant un container) avec des modalités de réplication et d'affectation

DaemonSet :

mettre en ligne un container avec création automatique sur les noeuds (exemple: un agent de monitoring)

Stateful :

mettre en ligne un pod (comme avec deployment) mais en lui affectant une identité fixe (sticky identity)

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'

Go est un langage assez central dans l'architecturede kubernetes, mais ce qui nous intéresse ici c'est l'output go-templace de kubectl. Celui-ci nous permet de forger notre output, et de faire des choses tricky.

A titre d'exemple, voici un script basique permettant de generer des yamls de tous les pods présent sur votre cluster"

kubectl get pods -A -o go-template='{{range .items}}microk8s kubectl get pod {{.metadata.name}} -n {{.metadata.namespace}} -o yaml >> {{.metadata.namespace}}.{{.metadata.name}}.yaml {{"\n"}}{{end}}' | sh

Bien sur ceci est basé sur une pratique courante de scripting, la construction de commandes à la volée avec un pipe en bout.

En tout cas, voici une façon amusante d'extraire les yaml de kubernetes !

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...

Il existe beaucoup de load tester pour les applis web : ab, k6, BlazeMeter...

Mais une à vraiment tester : Locust

pip3 install locust

Nous créons un stript python (non complet) qui contient une classe définissant les test à a effectuer :

from locust import HttpUser, between, task

class WebsiteUser(HttpUser):
    wait_time = between(5, 15)
    
    def on_start(self):
        self.client.post("/login", {
            "username": "test_user",
            "password": ""
        })
    
    @task
    def index(self):
        self.client.get("/")
        self.client.get("/static/assets.js")
        
    @task
    def about(self):
        self.client.get("/about/")

puis nous lancons locust avec ce script :

locust -f locustfile.py

Il y'a beaucoup plus à savoir bien sur, mais pour cela, RTFM

sudo snap install kontena-lens --classic

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

Certains serveur web, comme nextcloud, paramètrent internement des noms d'hôte valide. Quand on crée un liveness probe dans kube, celui-ci contacte http://ip:port/ et peut donc se faire rejeter alors que le site est fonctionnel.

Voici comment spécifier des options d'entêtes dans un liveness probe http de kubernetes :

ports:
- containerPort: 80
readinessProbe:
  httpGet:
    path: /login
    port: 80
    httpHeaders:
    - name: Host
      value:  "localhost"
  initialDelaySeconds: 30
  periodSeconds: 30
livenessProbe:
  httpGet:
    path: /login
    port: 80
    httpHeaders:
    - name: Host
      value:  "localhost"
  initialDelaySeconds: 15
  periodSeconds: 30  

A savoir aussi, qu'ingress prends le premier pod marqué ready comme liveness check pour gke. Si vous modifiez ces test sur pod après création d'une route ingress, il faut détruire et recréer la route ingress.

Il arrive que certains PV soient protégés contre la destruction. Pour le vérifier :

kubectl describe pvc PVC_NAME | grep Finalizers

on voit alors :

Finalizers:    [kubernetes.io/pvc-protection]

kubectl patch pvc PVC_NAME -p '{"metadata":{"finalizers": []}}' --type=merge

le pv est maintenant destructible. D'ailleurs, si vous n'arriviez pas à le detruire, et que la commande de destruction restait en plan, celle-ci prendra effet dès le patch appliqué.

Pour accéder au dashboard (et d'autres applications), il vous faut le token admin

Export de la config kubenertes

Vos identifiants et/ou votre token y sont :

kubectl config view 

Extraction par secret (kube self hosted ou microk8s)

Sans namespace :

microk8s kubectl get secret | awk '{if (/token/) system ("microk8s kubectl describe secret " $1)}'

Avec namespace :

kubectl -n kube-system get secret | awk '{if (/admin-user/) system ("kubectl -n kube-system describe secret " $1)}'

Vous pouvez aussi changer de namespace avant d'exécuter les commandes pour vous affranchir des "-n".

Google Kubernetes Engine

gcloud config config-helper --format=json | jq -r '.credential.access_token'

Kubernetes peut nous aider à la génération d'un déploiement :

comme on peut déployer avec la commande :

kubectl create deployment fancyapp --image test

on peut alors faire un dry-run et faire un output en yaml comme suit :

kubectl create deployment fancyapp --image test -o yaml --dry-run

Et voila notre squelette !

Il est possible pour simplifier ou enrichir, selon sa propre topologie de cluster kubernetes, d'enrichir celui-ci de plugins. Les plus plugins les plus simple sont des scripts shells, que l'ont va simplement déclarer comme tel. Pour plus d'informations, lire la documentation

Mais ce qui nous intéresse vraiment ici, c'est un petit bloc de cette documentaiton, qui parle du manager de plugin krew

Pour l'installer, il suffit de suivre cette documentation

Mettre à jour la liste de plugins

kubectl krew update

Lister les plugins

kubectl krew search

Installer un plugin

kubectl krew install access-matrix

utiliser le plugin

kubectl access-matrix

L'un des plugin les plus intéressant est ksniff

kubectl krew install ksniff
kubectl sniff db2http-6cb54d9c6f-w7dcn  -f "port 5000" -o - | tshark -r -

Et nous obtenons une écoute réseau du port 5000 de notre container flask dans un contexte interne à kubernetes !!!

    1   0.000000    10.60.0.1 → 10.60.0.19   TCP 76 54502 → 5000 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=2264947788 TSecr=0 WS=128
    2   0.000018   10.60.0.19 → 10.60.0.1    TCP 76 5000 → 54502 [SYN, ACK] Seq=0 Ack=1 Win=28160 Len=0 MSS=1420 SACK_PERM=1 TSval=3960258476 TSecr=2264947788 WS=128
    3   0.026261    10.60.0.1 → 10.60.0.19   TCP 68 54502 → 5000 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=2264947814 TSecr=3960258476
    4   0.028300    10.60.0.1 → 10.60.0.19   IPA 150 unknown 0x54 
    5   0.028316   10.60.0.19 → 10.60.0.1    TCP 68 5000 → 54502 [ACK] Seq=1 Ack=83 Win=28160 Len=0 TSval=3960258504 TSecr=2264947815
    6   0.030224   10.60.0.19 → 10.60.0.1    IPA 85 unknown 0x54 
    7   0.030369   10.60.0.19 → 10.60.0.1    IPA 205 unknown 0x6e 
    8   0.055745    10.60.0.1 → 10.60.0.19   TCP 68 54502 → 5000 [ACK] Seq=83 Ack=18 Win=64256 Len=0 TSval=2264947844 TSecr=3960258506
    9   0.056696    10.60.0.1 → 10.60.0.19   TCP 68 54502 → 5000 [FIN, ACK] Seq=83 Ack=156 Win=64128 Len=0 TSval=2264947845 TSecr=3960258506
   10   0.056708   10.60.0.19 → 10.60.0.1    TCP 68 5000 → 54502 [ACK] Seq=156 Ack=84 Win=28160 Len=0 TSval=3960258533 TSecr=2264947845

Les ip nous confrment bien que nous sommes dans le réseau interne de kubernetes, et non pas sur une écouté externe. D'ailleurs pour une écoute externe, le problème serait d'être positionné sur le load balancer, donc l'ip est attribuée dynamiquement, et n'est pas une ressource physique en tant que tel

Certains pods n'ont pas vocation a être exposés (posgress, grafana, ...)

Nous pourrions utiliser des tunnels ssh, mais cela demanderai une forme d'exposition (nodePort, à minima) et une connaissance des IP des pods, ce qui dans kubernetes et son allocation dynamique est plutôt "tricky" (pas vraiment compliqué, mais surtout pénible à faire à chaque fois quand mieux existe).

Mais heureusement, kubernetes propose un système de port forwarding pour pallier au problème.

kubectl port-forward -n monitoring grafana-core-6dfd47c968-wkkwk 3000:3000 --address 0.0.0.0

Bon, il faut quand même connaitre le nom du pod pour cela, mais un petit script utilisant grep ou awk pour extraire un pattern comme "grafana-core" n'a rien de sorcier. il est même possible d'automatiser un autoexpose port avec python et les multiples libs de kube, docker, etc. en s'y prenant bien !

Bref, encore des choses à faire, et surtout une grand part lié a la connaissance de l'écosystème kube.

Surement l'un des liens les plus utile du site

Plutot que d'installer kubernetes officiel sur plusieurs noeuds pour tester ou s'autoformer à kubernetez, il existe des version plus simples à installer comme microk8s :

snap install microk8s
microk8s enable
microk8s start
microk8s enable dns storage
alias kubectl = "microk8s kubectl"

Pour activer le dashboard :

microk8s enable dashboard
token=$(microk8s kubectl -n kube-system get secret | grep default-token | cut -d " " -f1)
microk8s kubectl -n kube-system describe secret $token
microk8s kubectl port-forward -n kube-system service/kuberInetes-dashboard 10443:443

Tant que le port-forward est actif, vous avez accès au dashboard par la boucle locale, port 10443, et donc un tunnel ssh. Le token affiché est le token vous permettant de vous authentifier.

Une fois tout ceci fait, vous pouvez commencer à jouer !

Pour debunker la création de droits pour les services et autres:

https://github.com/liggitt/audit2rb...

Kubernetes, ce que j'ai fait :

 Création d'un compte google cloud 
 Installation du sdk google : https://cloud.google.com/sdk
 Installation de kubectl : gcloud components install kubectl

Paramétrage de gcloud :

 gcloud config set compute/zone europe-west2-a 
 gcloud auth login 
 gcloud config set project gentle-booking-214421

Création d'un cluster sous google cloud :

 google containers cluster create pommeraie 
 kubectl get nodes

Reconnection au cluster depuis une autre machine

 gcloud container clusters get-credentials pommeraie

Création d'un yaml nginx :

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

Création des pods :

 kubectl create -f dep-nginx.yaml
 kubectl get pods

Destruction des pods :

 kubectl delete -f dep-nginx.yaml

Scaling des replicas du pod :

 kubectl scale --replicas=6 deployment nginx-deployment

Création d'un autoscaling :

 kubectl get rs
 kubectl autoscale deployment nginx-deployment  --min=2 --max=5 --cpu-percent=80
 kubectl get hpa
 kubectp get rs
 kubectl get pods

on voit bien qu'on est passé à 2 pods dispos.

Destruction de l'autoscaling :

 kubectl delete hpa nginx-deployment
 kubeclt get rs

Exposition d'un groupe de pod avec mise en place d'un load balancer :

 kubectl expose deployment nginx-deployment --type=LoadBalancer --name=lba-nginx
 kubectl get services

Récupération des informations de mon cluster :

 kubectl get nodes -o wide
 kubectl get pods -o wide
 kubectl get service -o wide
 kubectl get rs -o wide
 kubectl get hpa -o wide

Demande plus spécifique d'infos ;

 kubectl describe service lda-nginx

Lister tous les rôles de votre cluster :

 kubectl get clusterroles
 kubectl describe clusterroles