¶ Les fondamentaux
¶ Les certificats
PKI : Public Key Infrastructure
CA : Certificate Authority
- Le CA est celui qui valide tous les certificats qui sont dans le cluster.
- Tous les certificats du cluster sont signés par ce CA.
- Cela permet aux différents composants de se valider les uns les autres.
Par exemple le CA signe les certificats suivants :
Il existe 2 types de certificats, le client et le serveur :
¶ Retrouver les certificats
La plupart des certificats se trouvent dans le dossier /etc/kubernetes/pki :
- CA, apiserver cert, apiserver etcd client cert (permet la communication avec etcd), apiserver kubelet client cert (permet la communication avec kubelet)
root@cks-master:/etc/kubernetes/pki# ll
total 68
drwxr-xr-x 3 root root 4096 Apr 23 14:52 ./
drwxr-xr-x 4 root root 4096 Apr 23 14:52 ../
-rw-r--r-- 1 root root 1155 Apr 23 14:52 apiserver-etcd-client.crt
-rw------- 1 root root 1679 Apr 23 14:52 apiserver-etcd-client.key
-rw-r--r-- 1 root root 1164 Apr 23 14:52 apiserver-kubelet-client.crt
-rw------- 1 root root 1679 Apr 23 14:52 apiserver-kubelet-client.key
-rw-r--r-- 1 root root 1285 Apr 23 14:52 apiserver.crt
-rw------- 1 root root 1675 Apr 23 14:52 apiserver.key
-rw-r--r-- 1 root root 1099 Apr 23 14:52 ca.crt
-rw------- 1 root root 1675 Apr 23 14:52 ca.key
drwxr-xr-x 2 root root 4096 Apr 23 14:52 etcd/
-rw-r--r-- 1 root root 1115 Apr 23 14:52 front-proxy-ca.crt
-rw------- 1 root root 1675 Apr 23 14:52 front-proxy-ca.key
-rw-r--r-- 1 root root 1119 Apr 23 14:52 front-proxy-client.crt
-rw------- 1 root root 1679 Apr 23 14:52 front-proxy-client.key
-rw------- 1 root root 1679 Apr 23 14:52 sa.key
-rw------- 1 root root 451 Apr 23 14:52 sa.pub
- Etcd server cert se situe dans
/etc/kubernetes/pki/etcd:
root@cks-master:/etc/kubernetes/pki/etcd# ll
total 40
drwxr-xr-x 2 root root 4096 Apr 23 14:52 ./
drwxr-xr-x 3 root root 4096 Apr 23 14:52 ../
-rw-r--r-- 1 root root 1086 Apr 23 14:52 ca.crt
-rw------- 1 root root 1679 Apr 23 14:52 ca.key
-rw-r--r-- 1 root root 1159 Apr 23 14:52 healthcheck-client.crt
-rw------- 1 root root 1675 Apr 23 14:52 healthcheck-client.key
-rw-r--r-- 1 root root 1204 Apr 23 14:52 peer.crt
-rw------- 1 root root 1675 Apr 23 14:52 peer.key
-rw-r--r-- 1 root root 1204 Apr 23 14:52 server.crt
-rw------- 1 root root 1675 Apr 23 14:52 server.key
-
Scheduler ➔ apiserver se situe dans le fichier de configuration scheduler.conf dans
/etc/kubernetes/scheduler.conf, dans la partieclient-certificate-data -
Controller manager ➔ apiserver se situe dans le fichier de configuration
/etc/kubernetes/controller-manager.conf, dans la partieclient-certificate-data -
Kubelet ➔ apiserver dans
/etc/kubernetes/kubelet.conf, dans la partieclient-certificate(ici c'est un chemin d'accès) -
Kubelet server cert dans
/var/lib/kubelet/pki/:
root@cks-master:/var/lib/kubelet/pki# ll
total 20
drwxr-xr-x 2 root root 4096 Apr 23 14:52 ./
drwx------ 8 root root 4096 Apr 23 14:52 ../
-rw------- 1 root root 2826 Apr 23 14:52 kubelet-client-2022-04-23-14-52-47.pem
lrwxrwxrwx 1 root root 59 Apr 23 14:52 kubelet-client-current.pem -> /var/lib/kubelet/pki/kubelet-client-2022-04-23-14-52-47.pem
-rw-r--r-- 1 root root 2266 Apr 23 14:52 kubelet.crt
-rw------- 1 root root 1679 Apr 23 14:52 kubelet.key
¶ Les containers en profondeurs
¶ Containers et Images
Pour rappel un container :
- Run une ou plusieurs applications (préférer une application par container)
- Inclus toutes les dépendances de cette application
- D'un point de vu Linux, un container = un process Linux sur la machine hôte. Ce process est isolé.
¶ Namespaces
PID : Isole les processes entre eux. Un process ne voit pas les autres. Le Process ID (PID) 1 peut exister plusieurs fois ➔ le PID 1 est en général le process qui est lancé par l'application dans le container.
Mount : Restreint l'accès aux fichiers systèmes ainsi qu'aux disques montés
Network : Accède à certains périphériques réseaux. Permet de faire du pare-feu, routage... Directement via docker. Le trafic d'un container n'est pas capable de voir le trafic des autres, il n'est pas non plus capable de contacter toutes les autres interfaces selon configuration.
User : Utilisation de différents user id. Exemple : l'utilisateur 0 dans un namespace peut-être différente de l'utilisateur 0 dans un autre namespace.
¶ Isolation
Namespaces : Restreint ce que les processes peuvent voir (les autres processes, utilisateurs, fichiers systèmes)
Cgroups : Restreint l'usage de ressources des containers (RAM, Disque, CPU...)
¶ Pratique
Nous allons créer 2 containers et voir les process pour voir les process qui tournent dans les containers et sur la machine hôte :
Antoine@cks-master:~$ docker exec c1 ps aux
a2d555928fee961abfb3f4e4d0a5bfd6d32a3f727e2e0f999544909eacfb4bed
Antoine@cks-master:~$ docker exec c1 ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.2 0.0 2880 1000 ? Ss 21:41 0:00 sh -c sleep 1d
root 7 0.0 0.0 2780 1036 ? S 21:41 0:00 sleep 1d
root 8 0.0 0.0 7052 1536 ? Rs 21:42 0:00 ps aux
Dans le container c1 on voit qu'il n'y a que le process sleep 1d qui tourne.
Antoine@cks-master:~$ docker run --name c2 -d ubuntu sh -c 'sleep 90d'
365e62008a55f15b6b7ac5d52552c4cf207afb33cc13e1339acaf148deb70ec0
Antoine@cks-master:~$ docker exec c2 ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 1.0 0.0 2880 980 ? Ss 21:42 0:00 sh -c sleep 90d
root 7 0.0 0.0 2780 1028 ? S 21:42 0:00 sleep 90d
root 8 0.0 0.0 7052 1648 ? Rs 21:42 0:00 ps aux
Dans le container c2 on voit qu'il n'y a que le process sleep 90d qui tourne et non sleep 1d.
Et en regardant les process sur la machine hôte :
Antoine@cks-master:~$ ps aux | grep sleep
root 6774 0.0 0.0 2880 1000 ? Ss 21:41 0:00 sh -c sleep 1d
root 6833 0.0 0.0 2780 1036 ? S 21:41 0:00 sleep 1d
root 6936 0.3 0.0 2880 980 ? Ss 21:42 0:00 sh -c sleep 90d
root 6989 0.0 0.0 2780 1028 ? S 21:42 0:00 sleep 90d
Antoine 7038 0.0 0.0 14852 1040 pts/0 S+ 21:42 0:00 grep --color=auto sleep
On voit bien les 2 process des 2 containers c1 et c2.
On va maintenant associer un container au même namespace que c1 :
Antoine@cks-master:~$ docker run --name c3 --pid=container:c1 -d ubuntu sh -c 'sleep 30d'
67e31934b56413b6035033c844a5cae5fb6636ed2f5935967ec7ab3c44d77b38
Antoine@cks-master:~$ docker exec c3 ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 2880 1000 ? Ss 21:41 0:00 sh -c sleep 1d
root 7 0.0 0.0 2780 1036 ? S 21:41 0:00 sleep 1d
root 15 0.4 0.0 2880 1004 ? Ss 21:50 0:00 sh -c sleep 30d
root 22 0.0 0.0 2780 1032 ? S 21:50 0:00 sleep 30d
root 23 0.0 0.0 7052 1588 ? Rs 21:50 0:00 ps aux
On voit maintenant les 2 processes dans les containers c3 et c1.