Chapitre 2. Travailler avec des pods
2.1. Utilisation des dosettes
Un pod est un ou plusieurs conteneurs déployés ensemble sur un hôte, et la plus petite unité de calcul qui peut être définie, déployée et gérée.
2.1.1. Comprendre les dosettes
Les pods sont l'équivalent approximatif d'une instance de machine (physique ou virtuelle) pour un conteneur. Chaque pod se voit attribuer sa propre adresse IP interne, et possède donc tout son espace portuaire. Les conteneurs au sein des pods peuvent partager leur stockage local et leur réseau.
Les pods ont un cycle de vie ; ils sont définis, puis ils sont affectés à l'exécution sur un nœud, puis ils s'exécutent jusqu'à ce que leur(s) conteneur(s) se termine(nt) ou qu'ils soient supprimés pour une autre raison. Les pods, en fonction de la politique et du code de sortie, peuvent être supprimés après la sortie, ou peuvent être conservés pour permettre l'accès aux journaux de leurs conteneurs.
OpenShift Container Platform considère les pods comme largement immuables ; il n'est pas possible d'apporter des modifications à la définition d'un pod pendant qu'il est en cours d'exécution. OpenShift Container Platform met en œuvre les changements en mettant fin à un pod existant et en le recréant avec une configuration modifiée, une ou plusieurs images de base, ou les deux. Les pods sont également considérés comme consommables et ne conservent pas d'état lorsqu'ils sont recréés. C'est pourquoi les pods doivent généralement être gérés par des contrôleurs de niveau supérieur, plutôt que directement par les utilisateurs.
Pour connaître le nombre maximum de pods par hôte de nœud OpenShift Container Platform, voir les limites du cluster.
Les pods nus qui ne sont pas gérés par un contrôleur de réplication ne seront pas reprogrammés en cas d'interruption du nœud.
2.1.2. Exemples de configurations de pods
OpenShift Container Platform exploite le concept Kubernetes d'un pod, qui est un ou plusieurs conteneurs déployés ensemble sur un hôte, et la plus petite unité de calcul qui peut être définie, déployée et gérée.
Voici un exemple de définition d'un pod à partir d'une application Rails. Il démontre de nombreuses caractéristiques des pods, dont la plupart sont abordées dans d'autres sujets et ne sont donc que brièvement mentionnées ici :
Pod définition de l'objet (YAML)
kind: Pod
apiVersion: v1
metadata:
name: example
namespace: default
selfLink: /api/v1/namespaces/default/pods/example
uid: 5cc30063-0265780783bc
resourceVersion: '165032'
creationTimestamp: '2019-02-13T20:31:37Z'
labels:
app: hello-openshift 1
annotations:
openshift.io/scc: anyuid
spec:
restartPolicy: Always 2
serviceAccountName: default
imagePullSecrets:
- name: default-dockercfg-5zrhb
priority: 0
schedulerName: default-scheduler
terminationGracePeriodSeconds: 30
nodeName: ip-10-0-140-16.us-east-2.compute.internal
securityContext: 3
seLinuxOptions:
level: 's0:c11,c10'
containers: 4
- resources: {}
terminationMessagePath: /dev/termination-log
name: hello-openshift
securityContext:
capabilities:
drop:
- MKNOD
procMount: Default
ports:
- containerPort: 8080
protocol: TCP
imagePullPolicy: Always
volumeMounts: 5
- name: default-token-wbqsl
readOnly: true
mountPath: /var/run/secrets/kubernetes.io/serviceaccount 6
terminationMessagePolicy: File
image: registry.redhat.io/openshift4/ose-ogging-eventrouter:v4.3 7
serviceAccount: default 8
volumes: 9
- name: default-token-wbqsl
secret:
secretName: default-token-wbqsl
defaultMode: 420
dnsPolicy: ClusterFirst
status:
phase: Pending
conditions:
- type: Initialized
status: 'True'
lastProbeTime: null
lastTransitionTime: '2019-02-13T20:31:37Z'
- type: Ready
status: 'False'
lastProbeTime: null
lastTransitionTime: '2019-02-13T20:31:37Z'
reason: ContainersNotReady
message: 'containers with unready status: [hello-openshift]'
- type: ContainersReady
status: 'False'
lastProbeTime: null
lastTransitionTime: '2019-02-13T20:31:37Z'
reason: ContainersNotReady
message: 'containers with unready status: [hello-openshift]'
- type: PodScheduled
status: 'True'
lastProbeTime: null
lastTransitionTime: '2019-02-13T20:31:37Z'
hostIP: 10.0.140.16
startTime: '2019-02-13T20:31:37Z'
containerStatuses:
- name: hello-openshift
state:
waiting:
reason: ContainerCreating
lastState: {}
ready: false
restartCount: 0
image: openshift/hello-openshift
imageID: ''
qosClass: BestEffort
- 1
- Les pods peuvent être "étiquetés" avec une ou plusieurs étiquettes, qui peuvent ensuite être utilisées pour sélectionner et gérer des groupes de pods en une seule opération. Les étiquettes sont stockées au format clé/valeur dans le hachage
metadata. - 2
- La politique de redémarrage des pods avec les valeurs possibles
Always,OnFailure, etNever. La valeur par défaut estAlways. - 3
- OpenShift Container Platform définit un contexte de sécurité pour les conteneurs qui spécifie s'ils sont autorisés à s'exécuter en tant que conteneurs privilégiés, à s'exécuter en tant qu'utilisateur de leur choix, et plus encore. Le contexte par défaut est très restrictif, mais les administrateurs peuvent le modifier si nécessaire.
- 4
containersspécifie un tableau d'une ou plusieurs définitions de conteneurs.- 5
- Le conteneur spécifie où les volumes de stockage externes sont montés dans le conteneur. Dans ce cas, il y a un volume pour stocker l'accès aux informations d'identification dont le registre a besoin pour faire des demandes à l'API OpenShift Container Platform.
- 6
- Spécifiez les volumes à fournir pour le module. Les volumes sont montés au chemin spécifié. Ne les montez pas à la racine du conteneur,
/, ni à un chemin identique dans l'hôte et le conteneur. Cela peut corrompre votre système hôte si le conteneur est suffisamment privilégié, comme l'hôte/dev/ptsfiles. Vous pouvez monter l'hôte en toute sécurité en utilisant/host. - 7
- Chaque conteneur du pod est instancié à partir de sa propre image de conteneur.
- 8
- Les pods qui font des requêtes à l'API de OpenShift Container Platform sont assez courants pour qu'il y ait un champ
serviceAccountpour spécifier l'utilisateur du compte de service auquel le pod doit s'authentifier lorsqu'il fait les requêtes. Cela permet un contrôle d'accès fin pour les composants d'infrastructure personnalisés. - 9
- Le module définit les volumes de stockage que son ou ses conteneurs peuvent utiliser. Dans ce cas, il fournit un volume éphémère pour un volume
secretcontenant les jetons du compte de service par défaut.Si vous attachez des volumes persistants qui ont un nombre élevé de fichiers à des pods, ces pods peuvent échouer ou prendre beaucoup de temps à démarrer. Pour plus d'informations, voir Lors de l'utilisation de volumes persistants avec un nombre élevé de fichiers dans OpenShift, pourquoi les pods ne démarrent-ils pas ou prennent-ils un temps excessif pour atteindre l'état "Ready" ?
Cette définition de pod ne comprend pas les attributs qui sont remplis automatiquement par OpenShift Container Platform après la création du pod et le début de son cycle de vie. La documentation sur les pods Kubernetes contient des détails sur la fonctionnalité et le but des pods.
2.1.3. Ressources supplémentaires
- Pour plus d'informations sur les pods et le stockage, voir Comprendre le stockage persistant et Comprendre le stockage éphémère.
