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.

Note

Pour connaître le nombre maximum de pods par hôte de nœud OpenShift Container Platform, voir les limites du cluster.

Avertissement

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, et Never. La valeur par défaut est Always.
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
containers spé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/pts files. 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 serviceAccount pour 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 secret contenant 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" ?

Note

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

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.