Accueiil
Products
Red Hat OpenShift Service on AWS
4
De préparer votre environnement
6.2. La planification de votre environnement en fonction des exigences de l’application

6.2. La planification de votre environnement en fonction des exigences de l’application

Ce document décrit comment planifier votre service Red Hat OpenShift sur l’environnement AWS en fonction des exigences de votre application.

Considérez un exemple d’environnement d’application:

Expand

Le type de pod	La quantité de gousse	La mémoire Max	Cœurs de CPU	Le stockage persistant
Apache	100	500 MO	0,5	1 GO
à propos de Node.js	200	1 GO	1	1 GO
à propos de PostgreSQL	100	1 GO	2	10 GO
JBoss EAP	100	1 GO	1	1 GO

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

La taille de l’instance pour les nœuds peut être modulée vers le haut ou vers le bas, selon vos préférences. Les nœuds sont souvent surengagés par des ressources. Dans ce scénario de déploiement, vous pouvez choisir d’exécuter des nœuds plus petits ou moins grands pour fournir la même quantité de ressources. Des facteurs tels que l’agilité opérationnelle et le coût par instance devraient être pris en considération.

Expand

Le type de nœud	La quantité	CPUs	LA RAM (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 à des environnements surengagés, et d’autres ne le font pas. La plupart des applications Java et des applications qui utilisent d’énormes pages sont des exemples d’applications qui ne permettraient pas de surengagement. Cette mémoire ne peut pas être utilisée pour d’autres applications. Dans l’exemple ci-dessus, l’environnement serait d’environ 30 pour cent surengagé, un ratio commun.

Les pods d’applications peuvent accéder à un service en utilisant des variables d’environnement ou DNS. En utilisant 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. Le serveur DNS conçu par cluster surveille l’API Kubernetes pour de nouveaux services et crée un ensemble d’enregistrements DNS pour chacun d’entre eux. Lorsque DNS est activé tout au long de votre cluster, tous les pods doivent automatiquement être en mesure de résoudre les services par leur nom DNS. La découverte de service à l’aide de DNS peut être utilisée au cas où vous devez aller au-delà de 5000 services. Lors de l’utilisation de variables d’environnement pour la découverte de service, si la liste d’arguments dépasse la longueur autorisée après 5000 services dans un espace de noms, alors les pods et les déploiements commenceront à échouer.

Désactiver les liens de service dans le fichier de spécification de service du déploiement pour surmonter ceci:

Exemple :

Kind: Template
apiVersion: template.openshift.io/v1
metadata:
  name: deploymentConfigTemplate
  creationTimestamp:
  annotations:
    description: This template will create a deploymentConfig with 1 replica, 4 env vars and a service.
    tags: ''
objects:
  - kind: DeploymentConfig
    apiVersion: apps.openshift.io/v1
    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
  - kind: Service
    apiVersion: v1
    metadata:
      name: service${IDENTIFIER}
    spec:
      selector:
        name: replicationcontroller${IDENTIFIER}
      ports:
      - name: serviceport${IDENTIFIER}
        protocol: TCP
        port: 80
        targetPort: 8080
      portalIP: ''
      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: deploymentConfigTemplate

Kind: Template
apiVersion: template.openshift.io/v1
metadata:
  name: deploymentConfigTemplate
  creationTimestamp:
  annotations:
    description: This template will create a deploymentConfig with 1 replica, 4 env vars and a service.
    tags: ''
objects:
  - kind: DeploymentConfig
    apiVersion: apps.openshift.io/v1
    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
  - kind: Service
    apiVersion: v1
    metadata:
      name: service${IDENTIFIER}
    spec:
      selector:
        name: replicationcontroller${IDENTIFIER}
      ports:
      - name: serviceport${IDENTIFIER}
        protocol: TCP
        port: 80
        targetPort: 8080
      portalIP: ''
      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: deploymentConfigTemplate

Copy to Clipboard

Toggle word wrap

Le nombre de pods d’application pouvant s’exécuter dans un espace de noms dépend du nombre de services et de la longueur du nom de service lorsque les variables d’environnement sont utilisées pour la découverte de service. ARG_MAX sur le système définit la longueur d’argument maximale pour un nouveau processus et il est réglé sur 2097152 octets (2 MiB) par défaut. Le kubelet injecte des variables d’environnement dans chaque pod prévu pour s’exécuter dans l’espace de noms, y compris:

&LT;SERVICE_NAME&GT;_SERVICE_HOST=&LT;IP&GT;
&LT;SERVICE_NAME&GT;_SERVICE_PORT=&LT;PORT&GT;
&Lt;SERVICE_NAME>_PORT=tcp://<IP>:<PORT>
&Lt;SERVICE_NAME>_PORT_<PORT>_TCP=tcp://<IP>:<PORT>
&Lt;SERVICE_NAME>_PORT_<PORT>_TCP_PROTO=tcp
&LT;SERVICE_NAME&GT;_PORT_&LT;PORT&GT;_TCP_PORT=&LT;PORT&GT;
&LT;SERVICE_NAME&GT;_PORT_&LT;PORT&GT;_TCP_ADDR=&LT;ADDR&GT;

Les pods dans l’espace de noms commencent à échouer si la longueur de l’argument dépasse la valeur autorisée et si le nombre de caractères d’un nom de service l’affecte.

Retour au début

6.2. La planification de votre environnement en fonction des exigences de l’application

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Rendre l’open source plus inclusif

À propos de Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links