CKAD Auto-apprentissage Mod 4

Dans ce module du cours de préparation en ligne CKAD Broad Skills, nous couvrirons les concepts de base et les sujets de configuration identifiés par le programme d'examen CNCF CKAD. Si vous n'êtes pas déjà familiarisé avec le programme, prenez un moment pour vous familiariser car vous devrez démontrer une connaissance de chaque sujet afin de réussir l'examen.

Prestations de service

Un service est une abstraction d'un ensemble logique de pods qui permet de définir l'accès réseau entrant et sortant. Un service utilise un sélecteur pour cibler les pods à l'aide de l'étiquette des pods. Un service expose un ensemble logique de pods en tant que service réseau fournissant une seule adresse IP, un nom DNS ou un équilibrage de charge pour accéder aux pods. Le type de service est défini dans le manifeste. Les types de services suivants sont disponibles :

ClusterIP - expose le service sur une adresse IP interne dans le cluster Kubernetes (par défaut)NodePort - expose le service sur le même port de chaque nœud du cluster KubernetesExternalName - expose le service en utilisant un nom arbitraireLoadBalancer - crée un équilibreur de charge externe avec un fournisseur de cloud (par exemple GCE ForwardingRules, AWS Elastic Load Balancer, Azure Load Balancer) et attribue une adresse IP publique au service

Les services ClusterIP ne sont accessibles qu'à partir du cluster Kubernetes ; toutes les autres options peuvent gérer les demandes adressées au service depuis l'extérieur du cluster Kubernetes. Des services peuvent être créés impérativement pour une ressource en cours d'exécution. Au minimum, la ressource, l'objet et le port proxy exposé du service sont requis, par exemple kubectl expose [ressource] [objet] --port=[numéro de port] . Par défaut, si aucune autre option n'est donnée, un service ClusterIP est créé et le port spécifié est à la fois le port proxy du service sur le nœud local et le port cible du conteneur. L'exemple suivant crée un service pour un déploiement de deux pods nginx. Le port proxy du service est 8080 au port 80 du conteneur. Créez d'abord le déploiement de 3 réplicas de nginx et obtenez les points de terminaison des pods du déploiement. Nous pouvons utiliser l'étiquette d'exécution du déploiement pour afficher uniquement les pods du déploiement.

$ kubectl crée le déploiement nginx --image=nginx:latest --replicas=3

deploy.apps/nginx créé

$ kubectl get deploy --show-labels

NOM PRÊT À JOUR ÉTIQUETTES D'ÂGE DISPONIBLES

nginx 3/3 3 3 7s exécuter=nginx

$ kubectl get pods -l run=nginx -o wide

NOM ÉTAT PRÊT REDÉMARRAGE ÂGE NUD IP NUD NOMINÉ PORTES DE PRÉPARATION

nginx-9ffc7d87b-c6rmj 1/1 Exécution 0 79s 10.32.0.7 ubuntu

nginx-9ffc7d87b-rnfq4 1/1 Exécution 0 79s 10.32.0.5 ubuntu

nginx-9ffc7d87b-xq5r5 1/1 Exécution 0 79s 10.32.0.6 ubuntu

$

Politiques de réseau

Les stratégies réseau déterminent la manière dont les groupes de pods communiquent entre eux et avec les autres points de terminaison du réseau. La spécification de stratégie réseau utilise des sélecteurs d'étiquettes pour cibler les pods et définit des règles de trafic entrant et sortant pour ces pods. Par défaut, les pods acceptent le trafic de n'importe quelle source. Lorsqu'une stratégie réseau sélectionne des pods dans le même espace de noms, la stratégie réseau rejette toutes les connexions non autorisées par la stratégie réseau. Les stratégies réseau contrôlent l'entrée (entrant), la sortie (sortante) ou les deux types de trafic entre les pods. Un plug-in réseau Container Network Interface (CNI) implémente des politiques de réseau, un plug-in CNI est donc requis. Les stratégies réseau ne fonctionnent pas dans les clusters qui n'utilisent pas de plug-in CNI compatible. Les sélecteurs suivants sont utilisés par les règles réseau pour cibler les pods :

podSelector - sélectionne les pods à l'aide d'étiquettes (les pods doivent être dans le même espace de noms que la stratégie réseau)namespaceSelector - sélectionne les pods dans un espace de noms entier pour la source d'entrée ou de sortie destinationpodSelector et namespaceSelector - sélectionne les pods à partir d'un espace de noms spécifiqueipBlock - sélectionne les plages IP CIDR à autoriser comme source d'entrée ou destination de sortie

Les politiques de réseau ne peuvent pas être créées de manière impérative. La documentation Kubernetes fournit plusieurs exemples. Cet exemple refuse tout le trafic entrant vers les pods de l'espace de noms :

apiVersion : networking.k8s.io/v1

genre : NetworkPolicy

métadonnées :

nom : default-deny-ingress

spécification :

podSelector : {}

Types de politique :

- Entrée