Aller au contenu | Aller au menu | Aller à la recherche
samedi, juillet 13 2019
Par pepin le samedi, juillet 13 2019, 02:55
Après une désinstallation des packs kubernetes pour pouvoir faire une installe fraich, le tube résultat indique que les noeuds sont la depuis plus de 50 jours et not ready ...
La je commence à me dire que quelquechose cloche ...
Purger et reconfigurer Kube :
kubeadm reset -f
kubeadm init
et sur les noeuds :
kubeadm reset -f
kubeadm join ...
Un reboot fut aussi nécessaire aussi sur les noeuds pour arriver à un état final ou tout le monde indique être prêt.
Par pepin le samedi, juillet 13 2019, 01:42
Container trouvé sur le net en cherchant des scripts d'audit kubernetes :
docker run --pid=host -v /etc:/etc:ro -v /var:/var:ro -v $(which kubectl):/usr/bin/kubectl -v ~/.kube:/.kube -e KUBECONFIG=/.kube/config -t aquasec/kube-bench:latest master
Simple et pratique.
Vous auditez soit "master" soit "node" selon vos besons
vendredi, avril 26 2019
Par pepin le vendredi, avril 26 2019, 09:47
En espace containérisé, il faut forwarder les ports du container pour que ceux-ci sont visible comme émanant de hôte.
La ou dans docker, nous utilisons l'option -P pour faire cet export, dans kubernetes, il faut créer un service pour donner accès au port du container.
Dans un cas de test, c'est à la fois lourd et inutile, car on ne veut pas d'un service qui va persister, et créer pour détruire, c'est un peu gâcher.
Cependant dans kube, il est possible d'utiliser kubectl pour faire un port forward temporaire.
kubectl port-forward --address 0.0.0.0,localhost nginx-deployment-dc859774b-qqqs5 8080:80
Et a partir de la nous pouvons nous connecter sur http://kube-master:8080/ et voir le comportement du container nginx-deployment-dc859774b-qqqs5.
La spécification de l'adresse permet de choisir aussi si nous rendons ce test visible à tous nos clients (par défaut, elle n'est accessible qu'en loopback)
Voila, c'est tout.
mercredi, avril 24 2019
Par pepin le mercredi, avril 24 2019, 20:58
Dans mon cas de cluster multi architecture (arm+amd) je me heurte souvent au problème du "exec format error" avec des yaml récupéré sur les serveurs de google (comme le kube dashboard)...
Après avoir discuté avec mon meilleur ami et potassé de la doc, j'ai la solution à ce problème.
Dans la partie ''spec', nous ajoutons :
nodeSelector:
kubernetes.io/arch: arm
Nous pouvons aussi créer nos propres labels, et ainsi procéder à une allocation en fonction de ressources autres que l'architecture, comme par exemple des cas de prod/preprod, de modèles de disque
kubectl label nodes c16 pcl=preprod
kubectl label nodes c17 pcl=prod
kubectl label nodes c16 distype=ssd
kubectl label nodes c16 disktype=sata
kubectl label nodes c16 diskrpm=15000
Le tout est ouvert à l'imagination ... mais n'oubliez pas de vérifier au préalable les labels existants pour ne pas faire doublons 
Il y'a aussi, pour faire plus fin, les notions d'affinités dans kubernetes. Pour cela, je vous renvoie à la documentation en ligne.
lundi, avril 22 2019
Par pepin le lundi, avril 22 2019, 13:18
Une petite découverte, faite par un grand ami : K9S !
K9S fournir une interface cli pour votre cluster kubernetes et permet des opérations de lecture dessus.
Il s'installe, sur ubuntu, via snap :
snap install k9s --edge
Pour le lancer :
k9s --kubeconfig .kube/config -n all
le "-n all" est pour avoir tous les namespaces
Vous pouvez visiter le site du developpeur : https://k9ss.io/
samedi, mars 2 2019
Par pepin le samedi, mars 2 2019, 14:12
Dans Kubernetes, nous sommes, de part nature, containérisés. Impossible d'avoir un shell sur un container de l'intérieur du container, si aucun des container présents ne nous laisse faire un exec et fourni les outils que nous voudrions (nslookup, ping, traceroute ...)
Nous pouvons cependant entrer dans le cluster comme suit :
kubectl run busybox -it --image=busybox --restart=Never --rm
Cela créera un container dans le contexte du cluster, qui sera détruit lorsque nous le quitterons. De la nous pouvons faire des "nslookup" et surement plein d'autres choses !
vendredi, février 15 2019
Par pepin le vendredi, février 15 2019, 04:39
So far, so good ...
Maintenant que mon Dashboard fonctionne (je ne sais pas ce que j'avais raté avant donc je ne peux pas détailler cela), il me faut un compte pour me logguer.
En essayant le fichier de config, KO. En essayant un token, ca loggue. Mais les tokens que j'ai utilisé (ceux générés avec kubeadm token create) n'ont pas les droits suffisant pour administrer le cluster)
Un petit tour sur les commandes utiles autour des secret s'impose donc ...
kubeadm token list
kubectl -n kube-system get secret
C'est bien sur ici le namespace qui fait toute la différence.
kubectl -n kube-system describe secret username
Si on combine le tout :
kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}')
Maintenant nous allons créer un utilisateur admin pour le dashboard :
Fichier dashboard-adminuser.yml
apiVersion: v1 kind: ServiceAccount metadata: name: admin-user namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: admin-user roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: admin-user namespace: kube-system
attention à l'indentation comme toujours ...
Appliquer avec :
kubectl apply -f dashboard-adminuser.yml
Lancez votre dashboard en mode "fully exposed" :
kubectl proxy
Vous pouvez ensuite récupérer le token par les commandes indiquées précédemment, vous loguer, et constater que vous avez bien les accès admin !
mardi, novembre 20 2018
Par pepin le mardi, novembre 20 2018, 23:34
Dans un contexte multi architecture, kubernetes a un problème d'installation native. Il ne gère que l'architecture du maître. Mais grâce à cette page, j'ai pu faire fonctionner le tout.
Les documents n'étant pas éternels sur internet, je résume ici la manipulation :
Lors de la création d'un pod avec une commande "kubectl apply", nos nœuds arm ont leurs pods bloqué en Crashloopbackoff. Un examen avec kubectl describe pod <identifiant> ne nous permet pas de savoir pouvoir. Mais nous voyons le nœud sur lequel le pod tourne.
Une connexion sur ce nœud, et un petit docker describe <identifiant> du container généré par kubectl apply, permet d'obtenir l'emplacement des logs. La consultation de ces logs nous indique un problème de format binaire. L'image poussée par kube est une image amd64 et non arm !
Le problème provient du daemonset sur le maitre. Pour toutes la suite, faites attention aux indentations. C'est du yaml.
kubectl edit daemonset kube-proxy --namespace=kube-system
Après la ligne "hostNetwork: true", ajouter :
nodeSelector:
beta.kubernetes.io/arch: amd64
Ajouter aussi le même bloc dans la section spec/template/spec.
Enregistrer le fichier. Le daemonset est modifié.
Pour créer ce deuxième daemonset, nous relançons la commande d'édition, puis nous enregistrons le fichier sous le nom daemonset-arm.yaml.
Les modification à effectuer sont les suivantes :
Dans le bloc Metadata
Dans le bloc Spec
Supprimer tout le bloc status
Enregistrez le fichier, puis créer le nouveau daemonset avec la commande suivante :
kubectl create -f daemonset-arm.yaml
Une fois ce nouveau daemonset créé, nous pouvons joindre nos raspberry pi au cluster kubernetes, et il n'y aura plus de problèmes à la création des pods.
Nous pouvons voir le résultat avec la commande
kubectl get pods --namespace kube-system -o wide
samedi, novembre 10 2018
Par pepin le samedi, novembre 10 2018, 12:33
Dans ce post je décris l'installation d'un cluster kubernetes basé sur un portable comme maitre, et trois raspberry pi comme noeuds :
kubeadm init
kubectl apply -f https://git.io/weave-kube-1.6
kubeadm token create --print-join-command
La commande qui s'affiche sera exécutées sur les nœuds pour installer kubeadm, docker et rejoindre le cluster, en tant que root .
curl -sSL get.docker.com | sh
usermod pi -aG docker
dphys-swapfile swapoff
dphys-swapfile uninstall
update-rc.d dphys-swapfile remove
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list
apt-get update
apt-get install kubeadm
cp /boot/cmdline.txt /boot/cmdline_backup.txt
orig="$(head -n1 /boot/cmdline.txt) cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory"
echo $orig > /boot/cmdline.txt
reboot
kubeadm join ... --ignore-preflight-errors=all
les noeuds joignent le cluster sans problème !
un simple,
kubectl get nodes
nous permet de constater le résultat.
dimanche, septembre 30 2018
Par pepin le dimanche, septembre 30 2018, 01:18
sur tous ces objets, nous pouvons faire un :
kubectl get {item}
kubectl describe {item}
vendredi, septembre 28 2018
Par pepin le vendredi, septembre 28 2018, 18:56
ceci est une simple compte rendu de mes tests sur gcloud, en suivant la documentation k8s101 ansi que d'autres documentations.
Pour notre premier cluster kubernetes, nous suivons un tutoriel simple pour faire un cluster de nginx
Pour voir les noeuds de notre cluster kubernetes nous exécutons :
kubectl get nodes
Créer le fichier dep-nginx.yml comme suit :
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 4 # tells deployment to run 4 pods matching the template
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
attention à l'indentation !!
Pour instancier nos pods :
kubectl create -f dep-nginx.yml
Une fois notre cluster déployé, nous pouvons changer le nombre de replicas en modifiant le yaml et en ré-exécutant son instantiation.
Pour voire les pods instanciés :
kubectl get pods
Pour une description plus complète :
kubectl describe pods
Une fois cela fait, nous avons nos noeuds qui sont actifs, et font bien tourner un nginx, mais nous ne pouvons pas voir ceux-ci sur internet. Il faut les exposer, comme suit :
kubectl expose deployment nginx-deployment --type=LoadBalancer --name=lhb-nginx
Nous pouvons obtenir l'état de la publication et l'ip de mise à disposition avec la commande :
kubectl get services lhb-nginx
mardi, août 21 2018
Par pepin le mardi, août 21 2018, 09:08
Ce post est un condensée ce très bon document
De tout ca, il faudra écrire un role Ansible pour l'installation d'un serveur maitre kubernetes et serveurs noeuds kube...
apt-get update && apt-get install -y apt-transport-https
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list
apt-get update
apt-get install -y docker.io kubectl kubelet kubernetes-cni kubeadm
swapoff -a
kubeadm init
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
kubectl get nodes
kubectl apply -f https://git.io/weave-kube-1.6
après ca, un ssh sur les noeud pour exécuter les commandes suivantes :
kubeadm join **** --token **** --discovery-token-ca-cert-1 ****
puis controler sur le maitre que tous les noeuds sont la avec :
kubectl get nodes
page 2 de 2 - billets suivants »