1. Le mode réseau des dockers
obtient le numéro de processus du conteneur
docker inspect -f '{
{.State.Pid}}' ID du conteneur/nom du conteneur
Les caractéristiques du mode réseau docker
Dans l'état initial de docker, il existe trois modes réseau par défaut, bridg (bridge), host (hôte), none (pas de paramètres réseau)
[root@localhost ~]#docker network ls
Description de la configuration du mode réseau
host//host mode –network host Le conteneur et l'hôte partagent l'espace de noms réseau
container//container mode –network container : l'identifiant ou le nom du conteneur Le conteneur partage l'espace de noms réseau avec le conteneur spécifié
none// Pas de mode réseau - Le conteneur réseau aucun a son propre espace de noms de réseau, mais il n'y a pas de réglage
pont//mode pont - le conteneur de pont réseau a son propre espace de noms de réseau et a une adresse IP, un port, un routage, etc. indépendants, en utilisant la paire veth pour se connecter au pont docker0, et utiliser le pont docker0 comme passerelle
1.1 mode hôte hôte
Équivalent au mode pont dans Vmware, il est dans le même réseau que la machine hôte, mais n'a pas d'adresse IP indépendante. Docker utilise la technologie Linux Namespaces pour isoler les ressources, telles que le processus d'isolation PID Namespace, le système de fichiers d'isolation Mount Namespace, le réseau d'isolation Network Namespace, etc. Un espace de noms réseau fournit un environnement réseau indépendant, y compris les cartes réseau, le routage, les règles iptable, etc. sont isolés des autres espaces de noms réseau. Un conteneur Docker se voit généralement attribuer un Network.Namespace indépendant.
Cependant, si le mode hôte est utilisé lors du démarrage du conteneur, le conteneur n'obtiendra pas d'espace de noms réseau indépendant, mais partagera un espace de noms réseau avec l'hôte. Le conteneur ne virtualisera pas sa propre carte réseau, ne configurera pas sa propre IP, etc., mais utilisera l'IP et le port de l'hôte.
Le conteneur et l'hôte partagent l'espace de noms réseau, mais il n'y a pas d'adresse IP indépendante. L'adresse IP de l'hôte est utilisée et la plage de ports est partagée avec l'hôte. Par exemple, si l'hôte utilise le port 80, le conteneur ne peut pas utiliser le port 80. Ce mode est plus pratique, mais pas sûr.
#Créez le conteneur web1, spécifiez le mode réseau en tant qu'hôte
#Le conteneur et l'hôte partagent l'espace de noms du réseau, mais n'ont pas d'adresse IP indépendante. Utilisez l'adresse IP de l'hôte et partagez la plage de ports avec l'hôte.
docker run -d --name web1 --net=host nginx
#Accédez
à l'ip et au port 80 de la machine hôte, vous pourrez alors accéder au service nginx de tt1
curl http://192.168.50.24:80
1.2 mode conteneur
Après avoir compris le mode hôte, ce mode est facile à comprendre. Ce mode spécifie qu'un conteneur nouvellement créé partage un espace de noms réseau avec un conteneur existant au lieu de le partager avec l'hôte. Le conteneur nouvellement créé ne créera pas sa propre carte réseau, ne configurera pas son propre Ie, mais partagera re, plage de ports, etc. avec un conteneur spécifié. De même, en plus des aspects réseau des deux conteneurs, d'autres éléments tels que les systèmes de fichiers et les listes de processus sont toujours isolés. Les processus des deux conteneurs peuvent communiquer via le dispositif de carte réseau lo.
Le conteneur B et le conteneur A nouvellement créés partagent un espace de noms. Si le conteneur A utilise le port 80, le conteneur B ne peut pas utiliser le port 80.
#Créer un conteneur nommé web2 basé sur l'image centos:7
docker run -itd --name web2 centos:7 /bin/bash
#Afficher le numéro pid du conteneur web2
docker inspect -f '{
{.State.Pid}} 'web2
#Affichez l'espace de noms réseau de web2
ls -l /proc/web2's pid/ns
#Créez un conteneur web3, utilisez le mode réseau conteneur et partagez l'espace de noms réseau avec web2
docker run -itd --name web3 --net=container : web2 centos :7 bash
#Afficher le pid du conteneur web3
docker inspect -f '{
{.State.Pid}}' web3
ls -l /proc/web3's pid/ns/
#Vous pouvez voir que web3 et web2 partagent le même espace de noms réseau
1.3 aucun mode
En mode aucun, le conteneur Docker possède son propre espace de noms réseau, mais n'effectue aucune configuration réseau pour le conteneur Docker. C'est-à-dire que le conteneur de casier n'a pas de carte réseau, d'adresse IP, de routage et d'autres informations. Dans ce mode réseau, le conteneur n'a que le réseau de bouclage lo, et il n'y a pas d'autres cartes réseau.Ce type de réseau ne peut pas être connecté à Internet.Un réseau fermé peut bien garantir la sécurité du conteneur.
1.4 pont mode pont
Le mode pont est le mode réseau par défaut de docker, sans le paramètre --net, c'est le mode pont.
Équivalent au mode nat dans Vmware, le conteneur utilise un espace de noms .network indépendant et se connecte à la carte réseau virtuelle docker. Via dockerO bridge et iptables
La configuration de la table nat communique avec l'hôte. Ce mode allouera l'espace Mamespace, les paramètres, etc. pour chaque conteneur, et connectera un conteneur Docker sur un hôte à un pont de réseau virtuel.
(1) Lorsque le processus Docker démarre, un pont de réseau virtuel nommé docker0 sera créé sur l'hôte et le conteneur Docker démarré sur cet hôte sera connecté à ce pont virtuel. Le mode de fonctionnement du pont virtuel est similaire à celui d'un commutateur physique, de sorte que tous les conteneurs sur l'hôte sont connectés à un réseau de couche 2 via le commutateur.
(2) Attribuez une adresse IP au conteneur à partir du sous-réseau docker0 et définissez l'adresse I de dockerO comme passerelle par défaut du conteneur. Créez une paire de périphériques de paire veth NIC virtuels sur l'hôte. Les appareils Veth apparaissent toujours par paires et forment un canal de données. Lorsque des données entrent d'un appareil, elles sortent de l'autre appareil. Par conséquent, les appareils Veth sont souvent utilisés pour connecter deux appareils réseau.
(3) Docker place une extrémité du périphérique veth pair dans le conteneur nouvellement créé, et le nomme eth0 (la carte réseau du conteneur), et met l'autre extrémité dans l'hôte, nommé avec un nom similaire comme veth*, et ajoute ce périphérique réseau dans le pont docker0. Il peut être visualisé via la commande brctl show.
(4) Lors de l'utilisation de docker run -p, docker établit en fait des règles DNAT dans iptables pour réaliser la fonction de redirection de port. Vous pouvez utiliser iptables -t nat -vnL pour afficher.
[root@localhost opt]#docker run -id --name c1 centos:7
[root@localhost opt]#docker run -id --name c2 centos:7
[root@localhost opt]#docker run -id --name c3 centos:7
[root@localhost opt]#brctl show
[root@localhost opt]#docker run -id --name c4 -p 8080:80 centos:7
[root@localhost opt]#brctl show
[root@localhost opt ]#docker ps-a
1.5 Réseau personnalisé du conteneur
ifconfig docker0
Créez un réseau personnalisé :
docker network create --subnet=172.66.0.0/16 --opt "com.docker.network.bridge.name"="docker1" mynetwork
docker network create --subnet=172.66.0.0/16 -- opt "com.docker.network.bridge.name"="docker1" monréseau
Créez à nouveau le conteneur avec l'adresse IP spécifiée :
docker run -id --net=mynetwork --ip 172.66.0.66 --name a3 centos:7
ping 172.66.0.66
Expérience de production de réseau de conteneurs Docker, recommandations de réseau Docker et "contraste" IP hôte :
Par exemple, l'adresse de la machine hôte est 10.2.5.6 et l'adresse du conteneur peut être changée en 172.5.6.x, ce qui facilite la localisation du nœud défectueux lorsqu'une panne se produit.
Supprimer un réseau personnalisé :
Si vous souhaitez supprimer un réseau personnalisé, vous pouvez utiliser le nom du mode réseau docker network rm pour le supprimer, tel que docker network rm mynetwork.
Avant de supprimer un mode réseau, vous devez vous assurer que le conteneur créé à l'aide de ce mode réseau est sorti (c'est-à-dire arrêté). Le réseau ne peut pas être supprimé si le conteneur est toujours en cours d'exécution.
2. Contrôle des ressources des conteneurs Docker
Docker utilise les Cgroups pour contrôler les quotas de ressources utilisés par les conteneurs, y compris le processeur, la mémoire et le disque, ce qui couvre essentiellement les quotas de ressources communes et le contrôle de l'utilisation. Cgroup est l'abréviation de ControlGroups. C'est un mécanisme fourni par le noyau Linux qui peut limiter, enregistrer et isoler les ressources physiques (telles que le processeur, la mémoire, le disque, les io, etc.) utilisées par les groupes de processus. Il est utilisé par de nombreux projets tels que LXC et docker Implémenter le contrôle des ressources de processus. Cgroup lui-même est une infrastructure qui fournit des fonctions et des interfaces pour gérer les processus en groupes, et la gestion de ressources spécifiques telles que les E/S ou le contrôle de l'allocation de mémoire est réalisée via cette fonction.
Limite de ressources : vous pouvez limiter la quantité totale de ressources utilisées par la tâche.
Allocation prioritaire : à travers le nombre de tranches de temps CPU allouées et la taille de la bande passante d'E/S disque, cela revient en fait à contrôler la priorité d'exécution de la tâche.
Statistiques sur les ressources : vous pouvez compter l'utilisation des ressources du système, telles que la durée du processeur, l'utilisation de la mémoire, etc.
Contrôle des tâches : cgroup peut effectuer des opérations telles que la suspension et la reprise de tâches.
3. Limites sur le processeur hôte occupé par docker
3.1 Limite supérieure d'utilisation du processeur
Linux utilise CFS (Completely Fair Scheduler) pour planifier l'utilisation du processeur par chaque processus. La période de planification par défaut de CFS est de 100 ms. Nous pouvons définir le cycle de planification de chaque processus de conteneur et le temps CPU que chaque conteneur peut utiliser au maximum pendant ce cycle.
Utilisez --cpu-period pour définir la période de planification et utilisez --cpu-quota pour définir le temps CPU que le conteneur peut utiliser dans chaque période. Les deux peuvent être utilisés ensemble. La plage effective de la période CFS est de 1 ms ~ 1 s et la plage de valeurs de la --cpu-period correspondante est de 1000 ~ 1000000 (en microsecondes). Le quota de CPU du conteneur ne doit pas être inférieur à 1 ms, c'est-à-dire que la valeur de --cpu-quota doit être >= 1000. Le quota de CPU du conteneur ne doit pas être inférieur à 1 ms, c'est-à-dire que la valeur de --cpu-quota doit être >= 1000.
1 seconde = 1000 millisecondes = 1000000 microsecondes
cd /sys/fs/cgroup/cpu/docker/3ed82355f81151c4568aaa6e7bc60ba6984201c119125360924bf7dfd6eaa42b/
chat cpu.cfs_quota_us
-1
chat cpu.cfs_period_us
100000
--------------------------------------------- -------------------------------------------------- ----------
#cpu.cfs_period_us : La période d'allocation du processeur (microsecondes, donc le nom du fichier est représenté par nous), la valeur par défaut est 100000.
#cpu.cfs_quota_us : indique le temps (en microsecondes) que prend la limite de cgroups, et la valeur par défaut est -1, ce qui signifie qu'il n'y a pas de limite. S'il est réglé sur 50000, cela signifie que 50000/100000=50% du CPU est occupé.
(1) CPU normalement activé, testez la limite supérieure d'utilisation
#Créez un conteneur normalement (à ce moment, le conteneur suit la règle par défaut d'occupation des ressources du processeur)
[root@localhost ~]#docker run -id --name c1 centos :7
[root@localhost ~ ]#docker ps -a
[root@localhost ~]#docker exec -it c1 bash
[root@d6da0a6b999a /]# vi cpu.sh
#!/bin/bash
i=0
while true
do
let i++
done
[root@d6da0a6b999a / ]# chmod +x cpu.sh
démarrer le script de boucle infinie
[root@d6da0a6b999a /]# ./cpu.sh
À partir de ce résultat, on peut voir qu'il est très dangereux si la limite d'utilisation du processeur n'est pas limitée lors de la création d'un conteneur. Une fois que l'exception de programme d'un certain conteneur tombe dans une boucle infinie, cela conduira directement à l'interruption des activités dans autres contenants
(2) Modifiez la règle de limite supérieure de partage de temps du conteneur par défaut et créez à nouveau un test de démarrage pour
saisir directement la modification du fichier de configuration.
docker start c1
docker ps -a
#d6da0a6b999aeaac89e2ce883b6ff057abd5f4c2319d9a539635ff8e1f43fe04为容器id
cd /sys/fs/cgroup/cpu/docker/d6da0a6b999aeaac89e2ce883b6ff057 abd5f4c2319d9a539635ff8e1f43fe04
[root@localhost d6da0a6b999aeaac89e2ce883b6ff057abd5f4c2319d9a539635ff8e1f43fe04]#echo 50000 > cpu.cfs_quota_us
(3) Spécifiez la limite supérieure de l'utilisation des ressources cpu du conteneur lors de la création du conteneur
docker run -id --name c2 --cpu-quota 30000 centos:7
[root@localhost docker]#docker exec -it c2 bash
[ root@10cfa036ff07 /] # vim cpu.sh
#!/bin/bash
i=0
while true
do
let i++
done
[root@10cfa036ff07 /]# vi cpu.sh
[root@10cfa036ff07 /]# chmod +x cpu.sh
[ root@10cfa036ff07 /] # ./cpu.sh
（4）多cpu分配容器的使用上限
[root@localhost docker]#docker run -id --name c3 centos:7
[root@localhost docker]#docker ps -a
[root@localhost docker]#cd /sys/ fs/cgroup/cpu/docker/a1ce6948cdb6167570e6ef2101bb407d7de79407fbd9b9ac737ed40487f91a5a/
[root@localhost a1ce6948cdb6167570e6ef2101bb407d7de79407fbd9b9ac737 ed40487f91a5a]#ls
[root@localhost a1ce6948cdb6167570e6ef2101bb407d7de79407fbd9b9ac737ed40487f91a5a]#echo 200000 > cpu.cfs_quota_us
[root@localhost ~]#docker exec -it c3 bash
[root@a1ce6948cdb6 /]# vi cpu.bash
#!/bin/bash
i=0
while true
do
let i++
done
[root@a1ce6948cdb6 /]# chmod +x . /cpu.bash
[root@a1ce6948cdb6 /]# ./cpu.bash
3.2 Définir le taux d'occupation des ressources cpu
Remarque : Cette méthode ne prend effet que lorsque plusieurs conteneurs sont
définis La part de cpu est divisée par le nombre de parts allouées par le nombre de parts de cpu occupées par tous les conteneurs, qui est le pourcentage de ressources cpu occupées par le conteneur) à allouer
[root@localhost ~]#docker run -id --name b1 --cpu-shares 2048 centos:7
[root@localhost ~]#docker run -id --name b2 --cpu-shares 1024 centos:7
[root @localhost ~]#docker run -id --name b3 --cpu-shares 1024 centos:7
Ouvrez trois terminaux et démarrez le test de pression du conteneur :
#Trois conteneurs sont les opérations de mesure de pression suivantes
docker exec -it b1 bash
#Télécharger l'environnement dépendant de l'outil de mesure de la pression
yum install -y epel-release
#Télécharger l'outil de mesure de la pression
yum install -y stress
#Effectuer la mesure de la pression à quatre fils
stress -c 4
#Ouvrez un autre terminal pour afficher les résultats du test
docker stats
D'après les résultats des tests, on peut voir que lorsque le CPU alloue des tranches de temps, le conteneur b1 a deux fois plus d'opportunités que les conteneurs b2 et b3 d'obtenir des tranches de temps CPU. Cependant, le résultat de l'allocation dépend de l'état de fonctionnement de l'hôte et des autres conteneurs à ce moment-là.En fait, il n'y a aucune garantie que les conteneurs b2 et b3 pourront obtenir des tranches de temps cpu.
Par exemple, les processus des conteneurs b2 et b3 sont toujours inactifs, alors le conteneur b1 peut obtenir plus de tranches de temps CPU que les conteneurs b2 et b3. Dans les cas extrêmes, par exemple, un seul conteneur s'exécute sur l'hôte, même si sa part de CPU n'est que de 50, il peut monopoliser les ressources CPU de tout l'hôte.
Les Cgroups ne prendront effet que lorsque les ressources allouées par le conteneur sont rares, c'est-à-dire lorsque les ressources utilisées par le conteneur doivent être limitées. Par conséquent, il est impossible de déterminer combien de ressources CPU sont allouées à un conteneur en se basant simplement sur la part CPU d'un conteneur. Le résultat de l'allocation des ressources dépend de l'allocation CPU des autres conteneurs exécutés en même temps et de l'état d'exécution du processus dans le conteneur.
3.3 Définissez le conteneur pour lier le processeur spécifié
pour afficher le numéro de processeur dans le
haut de l'hôte
, appuyez sur le chiffre "1"
Liez le noyau pour créer un conteneur
[root@localhost ~]#docker run -id --name b4 --cpuset-cpus 2 centos:7
exec dans le conteneur pour les tests de résistance :
yum install -y epel-release
yum insatll -y stress
stress -c 1
4. Limites sur l'utilisation de la mémoire
4.1 Limiter la mémoire maximale qu'un conteneur peut utiliser
L'option m (ou --memory=) est utilisée pour limiter la mémoire maximale qu'un conteneur peut utiliser
docker run -itd --name d1 -m 512m centos:7 /bin/bash
docker stats
4.2 Limiter la taille d'échange disponible pour le conteneur
#Limiter la taille d'échange disponible, --memory-swap
●Pour souligner, --memory-swap doit être utilisé avec --memory (ou -m).
●Dans des circonstances normales, la valeur de --memory-swap inclut la mémoire disponible du conteneur et le swap disponible.
●Ainsi -m 300m --memory-swap=1g signifie : le conteneur peut utiliser 300M de mémoire physique et peut utiliser 700M (1G - 300M) d'échange. Si défini sur 0 ou non défini, la taille d'échange que le conteneur peut utiliser est le double de la valeur de -m. Si la valeur de --memory-swap est identique à la valeur de -m, le conteneur ne peut pas utiliser swap. Si la valeur --memory-swap est -1, cela signifie que la mémoire utilisée par le programme conteneur est limitée et que l'espace d'échange disponible n'est pas limité (l'hôte peut utiliser autant de conteneurs d'échange qu'il y en a).
La valeur de #--memory-swap inclut la mémoire disponible du conteneur et le swap disponible, moins la valeur de -m est la valeur du swap disponible.
#Indique que le conteneur peut utiliser 512 Mo de mémoire physique et peut utiliser 512 Mo de swap. Parce que 1g moins 512m de
mémoire physique, la valeur restante est le swap disponible.
docker run -itd --name d2 -m 512m --memory-swap=1g centos:7 bash #
--memoryswap la valeur est la même que la valeur -m, ce qui signifie que le conteneur ne peut pas utiliser swap docker run -itd -- nom d3 - m 512m --memory-swap=512m centos:7 bash # Si la valeur de --memory-swap est définie sur 0 ou non définie, la taille de swap que le conteneur peut utiliser est le double de la valeur de - M. docker run -itd --name d4 -m 512m centos:7 bash # --memory-swap La valeur est -1, ce qui signifie que la mémoire utilisée par le programme conteneur est limitée, mais que l'espace d'échange utilisable n'est pas limité (hôte L'hôte peut utiliser autant de conteneurs d'échange qu'il en a). docker run -itd --name d5 -m 512m --memory-swap=-1 centos:7 bash
5. Limitation du contrôle de la configuration des E/S de disque (blkio)
-device-read-bps : limite la vitesse de lecture en bps (volume de données) sur un certain périphérique, et l'unité peut être kb, mb (M) ou gb.
--device-write-bps : limite la vitesse d'écriture en bps (volume de données) sur un certain périphérique, l'unité peut être kb, mb (M) ou gb.
La vitesse fait référence aux opérations de lecture et d'écriture par seconde 1M, 1G ou 1kb
--device-read-iops : Limite les iops (nombre de fois) pour lire un périphérique
--device-write-iops : limite les iops (nombre de fois) écrits sur un certain périphérique
5.1 La vitesse d'écriture du conteneur par défaut
[root@localhost ~]#docker run -id --name e1 centos:7
[root@localhost ~]#docker exec -it e1 bash
[root@8657384cb483 /]# dd if= /dev/zero of=/opt/test.txt bs=10M count=5 oflag=direct
## oflag=direct évite le cache causé par le système de lecture et d'écriture des fichiers, et évite d'affecter les résultats des tests
5.2 Créer un conteneur avec une limite de vitesse d'écriture
[root@localhost ~]#docker run -it --name e3 --device-write-bps /dev/sda:1M centos:7 /bin/bash [root@
6c1b8bcf6b44 /]# dd if=/dev/zero of=/opt/test.out bs=10M count=5 oflag=direct
6. Effacez l'espace disque occupé par
docker docker system prune -a peut être utilisé pour nettoyer le disque, supprimer les conteneurs fermés, les volumes de données inutiles et les réseaux.
élaguer le système docker -a