Marques

Catégories de formation

Technique Microsoft

Utilisateur final Microsoft

Auto-apprentissage CKAd

Module 1

Broad Skills propose une large gamme de services de conseil en technologie open source

NOUS CONTACTER

CKAD Auto-apprentissage Mod 1

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.

modules d'autoformation ckaD

Pods de base

Les pods sont l'unité atomique de déploiement dans Kubernetes et sont constitués d'un ou plusieurs conteneurs dans différents tableaux dans un PodSpec :

Conteneurs (obligatoire) - conteneurs de longue durée pour les applications, les proxys, les side-cars de journalisation/surveillance, etc. Conteneurs d'initialisation (facultatif) - conteneurs d'amorçage qui s'exécutent une fois pour amorcer les conteneurs d'applications de longue duréeConteneurs éphémères (facultatif) - une fonctionnalité alpha dans Kubernetes, ces conteneurs peuvent être ajoutés au moment de l'exécution pour un dépannage ad hoc

Un pod basique contiendrait un seul conteneur et pourrait être créé avec yaml ou impérativement :

$ kubectl lance ckad-basic-pod --image=nginx:latest

Contexte de sécurité

Il s'agit d'un paramètre dans un PodSpec qui améliore la sécurité d'un ou de tous les conteneurs d'un pod et qui a les paramètres suivants :

Contrôle d'accès discrétionnaire : définissez les paramètres d'ID utilisateur (UID) et d'ID de groupe (GID) pour les processus à l'intérieur du conteneur. pod avec privilégié = true accorde toutes les capacitésAppArmor : invoque des profils de programme prédéfinis pour restreindre les capacités de programmes individuelsSeccomp : contrôle précis des appels système d'un processus grâce à l'utilisation de politiques jsonAllowPrivilegeEscalation : contrôle si un processus peut obtenir plus de privilèges que son parent

Les paramètres S ecurityContext peuvent être définis pour le pod et/ou chaque conteneur du pod, par exemple :

apiVersion : v1

genre: Pod

métadonnées :

nom: ckad-training-pod

spécification :

securityContext : # pod securitycontext

Groupe fs : 2000

conteneurs :

- nom : ckad-training-container

image : nginx

securityContext : # contexte de sécurité du conteneur

capacités :

ajouter : ["NET_ADMIN"]

Requêtes et limites de ressources de conteneur

Les demandes de ressources et les limites sont définies par conteneur dans un pod. En spécifiant une demande de ressource, nous indiquons au planificateur Kubernetes la quantité _minimum_ de chaque ressource (CPU et mémoire) dont un conteneur aura besoin. En spécifiant des limites, nous définissons des contraintes de groupe de contrôle sur le nœud où le processus s'exécute. Un exemple de définition de requêtes/limites ressemble à :

apiVersion : v1

genre: Pod

métadonnées :

nom : ckad-ressource-pod

spécification :

conteneurs :

- nom : ckad-resource-container

image : mon application : v3.3

Ressources:

limites:

processeur : "1"

mémoire : « 1Gi »

demandes :

processeur : "0,5"

mémoire : "500 Mi"

ConfigMaps

Les ConfigMaps sont des artefacts de configuration découplés qui maintiennent la portabilité des applications conteneurisées.

La ressource API ConfigMap fournit des mécanismes pour injecter des conteneurs avec des données de configuration tout en gardant les conteneurs indépendants de Kubernetes. Un ConfigMap peut être utilisé pour stocker des informations détaillées telles que des propriétés individuelles ou des informations détaillées telles que des fichiers de configuration entiers ou des blobs JSON.

Il existe plusieurs façons de créer un ConfigMap : à partir d'un téléchargement de répertoire, d'un fichier ou à partir de valeurs littérales dans la ligne de commande, comme illustré dans l'exemple suivant :

$ kubectl create configmap ckad-example-config --from-literal foo=bar

Secrets

Les secrets contiennent des informations sensibles, telles que les mots de passe, les jetons OAuth et les clés SSH. Mettre ces informations dans un secret est plus sûr et plus flexible que de les mettre textuellement dans une définition de pod ou une image Docker !

Il existe trois types de secrets, expliqués par l'indicateur --help :

$ kubectl crée un secret --help

Créez un secret à l'aide de la sous-commande spécifiée.

Commandes disponibles :

docker-registry Créer un secret à utiliser avec un registre Docker

générique Créer un secret à partir d'un fichier local, d'un répertoire ou d'une valeur littérale

tls Créer un secret TLS

Exemple de création d'un secret impérativement :

$ kubectl crée un secret générique my-secret \

--from-literal=username=ckad-user \

--from-literal=password=Char1!3-K!10-Alpha-D31ta

Montage de ConfigMaps/Secrets en tant que volumes ou variables d'environnement

Les ConfigMaps et les Secrets sont montés par les pods en tant que volumes ou variables d'environnement à utiliser par un conteneur dans un pod. ConfigMaps et Secrets peuvent être utilisés avec un pod de deux manières :

Fichiers dans un volumeVariables d'environnement

Les secrets peuvent également être utilisés par le kubelet lors de l'extraction d'images pour un pod, appelé imagePullSecret. -training-docker-token ” en tant qu'imagePullSecret :

apiVersion : v1

genre: Pod

métadonnées :

nom : pod-config

spécification :

conteneurs :

- nom : nginx

image: nginx:dernière

imagePullSecrets :

- nom : ckad-training-docker-token

volumeMontages :

- nom : configuration