7.4. Comment planifier votre environnement en fonction des exigences de l'application


Prenons un exemple d'environnement d'application :

Type de cosseQuantité de goussesMémoire maximaleCœurs de l'unité centraleStockage permanent

apache

100

500 MO

0.5

1 GB

node.js

200

1 GB

1

1 GB

postgresql

100

1 GB

2

10 GB

JBoss EAP

100

1 GB

1

1 GB

Exigences extrapolées : 550 cœurs de CPU, 450 Go de RAM et 1,4 To de stockage.

La taille de l'instance pour les nœuds peut être modulée à la hausse ou à la baisse, selon vos préférences. Les nœuds sont souvent surchargés en ressources. Dans ce scénario de déploiement, vous pouvez choisir d'exécuter des nœuds supplémentaires plus petits ou moins de nœuds plus grands pour fournir la même quantité de ressources. Des facteurs tels que l'agilité opérationnelle et le coût par instance doivent être pris en compte.

Type de nœudQuantitéCPUsRAM (GB)

Nœuds (option 1)

100

4

16

Nœuds (option 2)

50

8

32

Nœuds (option 3)

25

16

64

Certaines applications se prêtent bien aux environnements de surengagement, d'autres non. La plupart des applications Java et des applications qui utilisent d'énormes pages sont des exemples d'applications qui ne permettraient pas un surengagement. Cette mémoire ne peut pas être utilisée pour d'autres applications. Dans l'exemple ci-dessus, l'environnement serait sur-engagé à environ 30 %, un ratio courant.

Les modules d'application peuvent accéder à un service en utilisant des variables d'environnement ou le DNS. Si l'on utilise des variables d'environnement, pour chaque service actif, les variables sont injectées par le kubelet lorsqu'un pod est exécuté sur un nœud. Un serveur DNS conscient du cluster surveille l'API Kubernetes pour les nouveaux services et crée un ensemble d'enregistrements DNS pour chacun d'entre eux. Si le DNS est activé dans l'ensemble de votre cluster, tous les pods devraient automatiquement être en mesure de résoudre les services par leur nom DNS. La découverte de services à l'aide du DNS peut être utilisée si vous devez aller au-delà de 5000 services. Lorsque vous utilisez des variables d'environnement pour la découverte de services, la liste d'arguments dépasse la longueur autorisée après 5000 services dans un espace de noms, les pods et les déploiements commenceront alors à échouer. Désactivez les liens de service dans le fichier de spécification de service du déploiement pour résoudre ce problème :

---
apiVersion: template.openshift.io/v1
kind: Template
metadata:
  name: deployment-config-template
  creationTimestamp:
  annotations:
    description: This template will create a deploymentConfig with 1 replica, 4 env vars and a service.
    tags: ''
objects:
- apiVersion: apps.openshift.io/v1
  kind: DeploymentConfig
  metadata:
    name: deploymentconfig${IDENTIFIER}
  spec:
    template:
      metadata:
        labels:
          name: replicationcontroller${IDENTIFIER}
      spec:
        enableServiceLinks: false
        containers:
        - name: pause${IDENTIFIER}
          image: "${IMAGE}"
          ports:
          - containerPort: 8080
            protocol: TCP
          env:
          - name: ENVVAR1_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR2_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR3_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR4_${IDENTIFIER}
            value: "${ENV_VALUE}"
          resources: {}
          imagePullPolicy: IfNotPresent
          capabilities: {}
          securityContext:
            capabilities: {}
            privileged: false
        restartPolicy: Always
        serviceAccount: ''
    replicas: 1
    selector:
      name: replicationcontroller${IDENTIFIER}
    triggers:
    - type: ConfigChange
    strategy:
      type: Rolling
- apiVersion: v1
  kind: Service
  metadata:
    name: service${IDENTIFIER}
  spec:
    selector:
      name: replicationcontroller${IDENTIFIER}
    ports:
    - name: serviceport${IDENTIFIER}
      protocol: TCP
      port: 80
      targetPort: 8080
    clusterIP: ''
    type: ClusterIP
    sessionAffinity: None
  status:
    loadBalancer: {}
parameters:
- name: IDENTIFIER
  description: Number to append to the name of resources
  value: '1'
  required: true
- name: IMAGE
  description: Image to use for deploymentConfig
  value: gcr.io/google-containers/pause-amd64:3.0
  required: false
- name: ENV_VALUE
  description: Value to use for environment variables
  generate: expression
  from: "[A-Za-z0-9]{255}"
  required: false
labels:
  template: deployment-config-template
Copy to Clipboard

Le nombre de modules d'application pouvant être exécutés dans un espace de noms dépend du nombre de services et de la longueur du nom du service lorsque les variables d'environnement sont utilisées pour la découverte des services. ARG_MAX sur le système définit la longueur maximale des arguments pour un nouveau processus et elle est fixée à 2097152 octets (2 MiB) par défaut. Le Kubelet injecte des variables d'environnement dans chaque pod programmé pour s'exécuter dans l'espace de noms, y compris :

  • <SERVICE_NAME>_SERVICE_HOST=<IP>
  • <SERVICE_NAME>_SERVICE_PORT=<PORT>
  • <SERVICE_NAME>_PORT=tcp://<IP>:<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP=tcp://<IP>:<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP_PROTO=tcp
  • <SERVICE_NAME>_PORT_<PORT>_TCP_PORT=<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP_ADDR=<ADDR>

Les pods de l'espace de noms commenceront à échouer si la longueur de l'argument dépasse la valeur autorisée et si le nombre de caractères dans le nom d'un service a un impact. Par exemple, dans un espace de noms comprenant 5000 services, la limite du nom de service est de 33 caractères, ce qui vous permet d'exécuter 5000 pods dans l'espace de noms.

Retour au début
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. Découvrez nos récentes mises à jour.

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 le Blog 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.

Theme

© 2025 Red Hat