7.4. Comment planifier votre environnement en fonction des exigences de l'application
Prenons un exemple d'environnement d'application :
Type de cosse | Quantité de gousses | Mémoire maximale | Cœurs de l'unité centrale | Stockage 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œud | Quantité | CPUs | 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 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
---
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
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.