Un Deployment gère un ensemble de pods identiques et garantit qu'un nombre spécifié reste en cours d'exécution en permanence. Il s'agit du type de charge de travail standard pour les applications sans état dans Kubernetes, c'est-à-dire des services qui ne dépendent pas d'un état local persistant, tels que les serveurs web, les backends d'API et les processeurs par lots.
Cette rubrique explique comment créer un Deployment dans un cluster ACK à l'aide de la console ou de kubectl.
Prérequis
Avant de commencer, assurez-vous de disposer des éléments suivants :
Un cluster ACK. Consultez la section Charges de travail pour comprendre les concepts et les considérations liés aux charges de travail.
-
Un accès Internet pour le cluster ou ses nœuds, car les exemples de démarrage rapide extraient une image publique :
(Recommandé) Activer l'accès Internet pour le cluster — crée une passerelle NAT Internet pour le VPC, offrant à toutes les ressources du cluster un accès sortant.
Attribuez une adresse IP publique statique à chaque nœud sur lequel la charge de travail s'exécute.
Créer un déploiement
Créer un Deployment à l'aide de la console
Les étapes ci-dessous décrivent le moyen le plus rapide d'obtenir un Deployment en cours d'exécution. Une fois que vous maîtrisez les bases, consultez la section Référence de configuration de la console pour personnaliser davantage la charge de travail.
-
Configurez les informations de base. Connectez-vous à la console Container Service for Kubernetes. Dans le volet de navigation de gauche, cliquez sur Clusters. Sur la page Clusters, cliquez sur le nom de votre cluster, puis choisissez Workloads > Deployments dans le volet de navigation de gauche. Sur la page Deployments, cliquez sur Create from Image. Sur la page Basic Information, définissez le nom de l'application et d'autres paramètres de base, puis cliquez sur Next pour accéder à la page Container.
-
Configure the container. Dans la section Container, définissez Image Name avec l'adresse suivante et définissez Port sur
80. Laissez tous les autres paramètres par défaut, puis cliquez sur Next pour accéder à la page Advanced.ImportantPour extraire cette image, le cluster doit avoir accès à Internet. Si vous avez sélectionné Configure SNAT for VPC lors de la création du cluster, l'accès Internet est déjà activé. Sinon, activez-le maintenant.
anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
-
Complete the advanced configuration. Sur la page Advanced, cliquez sur Create à droite de Services pour créer un service de type SLB afin d'exposer la charge de travail sur Internet. Configurez les options Scaling, Scheduling et Labels and Annotations selon vos besoins, puis cliquez sur Create en bas de la page.
ImportantLa création d'un service de type SLB provisionne une instance Server Load Balancer (SLB), ce qui entraîne des frais de paiement à l'utilisation. Consultez la section Paiement à l'utilisation pour plus de détails sur les tarifs. Libérez l'instance SLB lorsque vous n'en avez plus besoin.
-
Access the application. Sur la page Complete, cliquez sur View Details dans le panneau Creation Task Submitted. Cliquez sur l'onglet Access Method, recherchez le service nommé
nginx-test-svcet cliquez sur le lien dans la colonne External Endpoint. Depuis la page Deployments, vous pouvez View, Edit et Redeploy la charge de travail à tout moment.
Créer un Deployment à l'aide de kubectl
Connectez-vous au cluster avec kubectl avant de poursuivre. Consultez la section Obtenir le fichier kubeconfig d'un cluster et utiliser kubectl pour se connecter au cluster.
-
Copiez le contenu YAML suivant et enregistrez-le sous le nom
deployment.yaml. Il définit un Deployment avec deux réplicas et un service LoadBalancer qui expose le Deployment sur le port 80.apiVersion: apps/v1 kind: Deployment # Workload type metadata: name: nginx-test namespace: default # Change the namespace as needed labels: app: nginx spec: replicas: 2 # Specify the number of pods selector: matchLabels: app: nginx template: # Pod configuration metadata: labels: # Pod labels app: nginx spec: containers: - name: nginx # Container name image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6 # Use a specific version of the Nginx image ports: - containerPort: 80 # Port exposed by the container protocol: TCP # Specify the protocol as TCP or UDP. The default is TCP. --- # service apiVersion: v1 kind: Service metadata: name: nginx-test-svc namespace: default # Change the namespace as needed labels: app: nginx spec: selector: app: nginx # Match labels to ensure the service points to the correct pods ports: - port: 80 # Port provided by the service within the cluster targetPort: 80 # Points to the port listened to by the application inside the container (containerPort) protocol: TCP # Protocol. The default is TCP. type: LoadBalancer # Service type. The default is ClusterIP for internal access. -
Appliquez le manifeste :
kubectl apply -f deployment.yamlSortie attendue :
deployment.apps/nginx-test created service/nginx-test-svc created -
Exécutez la commande suivante pour afficher l'adresse IP publique du service :
kubectl get svcSortie attendue :
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 172.16.**.*** <none> 443/TCP 4h47m nginx-test-svc LoadBalancer 172.16.**.*** 106.14.**.*** 80:31130/TCP 1h10m -
Dans un navigateur, saisissez l'adresse IP publique de Nginx (106.14..*) pour accéder à l'application Nginx.
Référence de configuration de la console
Informations de base
|
Élément de configuration |
Description |
|
Name |
Nom de la charge de travail. Les noms des pods appartenant à la charge de travail sont générés à partir de ce nom. |
|
Namespace |
Espace de noms auquel appartient la charge de travail. |
|
Replicas |
Nombre de pods dans la charge de travail. La valeur par défaut est 2. |
|
Type |
Type de charge de travail. Pour choisir un type de charge de travail, consultez la section Créer une charge de travail. |
|
Label |
Libellés de la charge de travail. |
|
Annotations |
Annotations de la charge de travail. |
|
Synchronize Timezone |
Indique si le conteneur utilise le même fuseau horaire que le nœud sur lequel il réside. |
Conteneur
|
Élément de configuration |
Description |
|
Image Name |
|
|
Resource Limit |
Le paramètre |
|
Required Resources |
Le paramètre |
|
Container Start Parameter |
Ces deux options sont généralement utilisées conjointement pour lier le terminal ( |
|
Privileged Container |
Le mode privilégié accorde à un conteneur des autorisations similaires à celles du système d'exploitation de son nœud de calcul hôte, telles que l'accès aux périphériques matériels et le montage de systèmes de fichiers. |
|
Init Containers |
Sélectionnez cette option pour créer un conteneur d'initialisation. Les conteneurs d'initialisation offrent un mécanisme permettant de bloquer ou de retarder le démarrage des conteneurs d'application. Une fois que les conteneurs d'initialisation ont été exécutés avec succès, les autres conteneurs du pod démarrent en parallèle. Par exemple, vous pouvez vérifier la disponibilité des services dépendants. Les conteneurs d'initialisation peuvent inclure des outils utilitaires et des scripts d'installation qui ne figurent pas dans l'image de l'application pour initialiser l'environnement d'exécution du conteneur d'application, par exemple en définissant des paramètres de noyau ou en générant des fichiers de configuration. Pour plus d'informations, consultez la section Conteneurs d'initialisation. |
|
Élément de configuration |
Description |
|
Name |
Nom du port du conteneur. Il sert uniquement à distinguer les ports et n'a aucun effet fonctionnel. |
|
Container Port |
Port exposé par le conteneur. La valeur doit être comprise entre 1 et 65535. Un conteneur doit exposer un port pour être accessible depuis l'extérieur du pod et permettre la communication entre les conteneurs au sein du pod. Tous les conteneurs d'un pod partagent la pile de protocoles réseau du pod, donc les ports ne peuvent pas être dupliqués lors de la configuration de plusieurs conteneurs dans un pod. |
|
Protocol |
Protocole de couche 4 (couche transport) utilisé par le port du conteneur. TCP et UDP sont pris en charge. |
|
Élément de configuration |
Description |
|
Type |
Type de variable d'environnement. Les types suivants sont pris en charge :
Les éléments de configuration et les secrets prennent en charge le référencement de tous les fichiers. Prenons un secret comme exemple. Si vous sélectionnez le type Secret et ne sélectionnez que le secret cible, tous les fichiers sont référencés par défaut. Le fichier YAML correspondant référence également l'intégralité du secret. Si vous sélectionnez Resource Reference, le paramètre
|
|
Variable Key |
Nom de la variable d'environnement dans le pod. |
|
Value/ValueFrom |
Valeur de la variable d'environnement ou valeur obtenue à partir d'une autre source. |
|
Élément de configuration |
Description |
|
Liveness : Utilisé pour déterminer si un conteneur fonctionne normalement. Si un nombre spécifié de vérifications échoue, le kubelet redémarre le conteneur. Les sondes de vivacité peuvent détecter des problèmes qui maintiennent un conteneur dans un état en cours d'exécution mais qui ne répond pas, comme un interblocage. |
|
|
Readiness : Utilisé pour déterminer si un conteneur est prêt à accepter le trafic. Un pod est attaché au backend d'un service uniquement après la réussite de sa sonde de readiness. |
|
|
Startup : Exécutée uniquement au démarrage du conteneur pour vérifier s'il a démarré avec succès. La Liveness Probe et la Readiness Probe sont exécutées uniquement après la réussite de la sonde de démarrage. Remarque
Les sondes de démarrage sont prises en charge uniquement dans les clusters Kubernetes exécutant la version 1.18 ou ultérieure. |
|
Élément de configuration |
Description |
|
Start |
Définissez les commandes et paramètres de pré-démarrage pour le conteneur. La commande de démarrage et les paramètres définissent les actions à effectuer au démarrage du conteneur, utilisées pour initialiser le service d'application. Cela convient aux déploiements d'applications nécessitant des variables d'environnement spécifiques, des cibles de montage ou des mappages de ports. |
|
Post Start |
Définissez les commandes à exécuter après le démarrage du conteneur. Les commandes post-démarrage sont utilisées pour effectuer des tâches spécifiques après le démarrage du conteneur, telles que l'initialisation des configurations ou l'exécution de scripts. Cela convient aux scénarios où un travail de préparation doit être effectué avant le démarrage du processus principal. |
|
Pre Stop |
Définissez les commandes de pré-arrêt pour le conteneur. Les commandes de pré-arrêt sont utilisées pour arrêter le processus d'application à l'intérieur du conteneur, garantissant la cohérence des données et l'arrêt normal du service. Cela convient aux scénarios nécessitant un arrêt sécurisé pour éviter la perte de données ou des anomalies de service. |
|
Vous pouvez configurer la commande de démarrage, les gestionnaires post-démarrage et pré-arrêt pour le cycle de vie du conteneur. Pour plus d'informations, consultez la section Configurer le cycle de vie. |
|
Configuration avancée
|
Carte de configuration |
Élément de configuration |
Description |
|
Access Control |
Services |
Un service fournit un point d'entrée fixe et unifié de couche 4 (couche transport) pour un groupe de pods. C'est une ressource requise pour exposer une charge de travail. Les services prennent en charge plusieurs types, y compris Cluster IP, Node Port et SLB. Avant de configurer un service, consultez la section Gestion des services pour comprendre les bases des services. |
|
Ingresses |
Un Ingress fournit un point d'entrée de couche 7 (couche application) pour plusieurs services dans un cluster et transfère les requêtes vers différents services en fonction de la correspondance du nom de domaine. Avant d'utiliser un Ingress, vous devez installer un contrôleur Ingress. ACK propose plusieurs options pour différents scénarios. Consultez la section Comparaison de Nginx Ingress, ALB Ingress et MSE Ingress pour faire votre choix. |
|
|
Scaling |
HPA |
Déclenche la mise à l'échelle automatique en surveillant les métriques de performance des conteneurs. La mise à l'échelle basée sur les métriques vous aide à ajuster automatiquement les ressources totales utilisées par une charge de travail lorsque la charge métier fluctue, en augmentant la capacité pour gérer les charges élevées et en réduisant la capacité pour économiser des ressources pendant les faibles charges. Pour plus d'informations, consultez la section Utiliser Horizontal Pod Autoscaling (HPA). |
|
CronHPA |
Déclenche la mise à l'échelle de la charge de travail à des heures planifiées. Cela convient aux scénarios présentant des variations périodiques de la charge métier, comme les pics de trafic cycliques sur les réseaux sociaux après le déjeuner et le dîner. Pour plus d'informations, consultez la section Utiliser CronHPA pour la mise à l'échelle horizontale automatique planifiée des pods. |
|
|
Scheduling |
Upgrade Method |
Mécanisme par lequel une charge de travail remplace les anciens pods par de nouveaux lorsque la configuration des pods change.
|
|
Les configurations d'affinité, d'anti-affinité et de tolérance sont utilisées pour la planification afin de garantir que les pods s'exécutent sur des nœuds spécifiques. Les opérations de planification sont complexes et nécessitent une planification préalable en fonction de vos besoins. Pour des opérations détaillées, consultez la section Planification. |
|
|
Labels and Annotations |
Pod Labels |
Ajoute un libellé à chaque pod appartenant à cette charge de travail. Diverses ressources du cluster, y compris les charges de travail et les services, correspondent aux pods via les libellés. ACK ajoute un libellé par défaut aux pods au format |
|
Pod Annotations |
Ajoute une annotation à chaque pod appartenant à cette charge de travail. Certaines fonctionnalités d'ACK utilisent des annotations. Vous pouvez les modifier lors de l'utilisation de ces fonctionnalités. |
Exemple de YAML de charge de travail
Le YAML complet suivant illustre les options de configuration courantes, y compris les limites de ressources, les vérifications de l'état, les variables d'environnement issues d'un ConfigMap et un Ingress.
apiVersion: apps/v1
kind: Deployment # Workload type
metadata:
name: nginx-test
namespace: default # Change the namespace as needed
labels:
app: nginx
spec:
replicas: 2 # Specify the number of pods
selector:
matchLabels:
app: nginx
template: # Pod configuration
metadata:
labels: # Pod labels
app: nginx
annotations: # Pod annotations
description: "This is an application deployment"
spec:
containers:
- name: nginx # Image name
image: nginx:1.7.9 # Use a specific version of the Nginx image
ports:
- name: nginx # name
containerPort: 80 # Port exposed by the container
protocol: TCP # Specify the protocol as TCP or UDP. The default is TCP.
command: ["/bin/sh"] # Container start command
args: [ "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY) && exec nginx -g 'daemon off;'"] # Output variables, add command to start nginx
stdin: true # Enable standard input
tty: true # Allocate a virtual terminal
env:
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
name: special-config # Name of the configuration item
key: SPECIAL_LEVEL # Key name of the configuration item
securityContext:
privileged: true # true enables privileged mode, false disables it. The default is false.
resources:
limits:
cpu: "500m" # Maximum CPU usage, 500 millicores
memory: "256Mi" # Maximum memory usage, 256 MiB
ephemeral-storage: "1Gi" # Maximum ephemeral storage usage, 1 GiB
requests:
cpu: "200m" # Minimum requested CPU usage, 200 millicores
memory: "128Mi" # Minimum requested memory usage, 128 MiB
ephemeral-storage: "500Mi" # Minimum requested ephemeral storage usage, 500 MiB
livenessProbe: # Liveness probe configuration
httpGet:
path: /
port: 80
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe: # Readiness probe configuration
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 10
volumeMounts:
- name: tz-config
mountPath: /etc/localtime
readOnly: true
volumes:
- name: tz-config
hostPath:
path: /etc/localtime # Mount the host's /etc/localtime file to the same path in the container using volumeMounts and volumes fields.
---
# service
apiVersion: v1
kind: Service
metadata:
name: nginx-test-svc
namespace: default # Change the namespace as needed
labels:
app: nginx
spec:
selector:
app: nginx # Match labels to ensure the service points to the correct pods
ports:
- port: 80 # Port provided by the service within the cluster
targetPort: 80 # Points to the port listened to by the application inside the container (containerPort)
protocol: TCP # Protocol. The default is TCP.
type: ClusterIP # Service type. The default is ClusterIP for internal access.
---
# ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: nginx-ingress
namespace: default # Change the namespace as needed
annotations:
kubernetes.io/ingress.class: "nginx" # Specify the Ingress controller type
# If using Alibaba Cloud SLB Ingress controller, you can specify the following:
# service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "lb-xxxxxxxxxx"
# service.beta.kubernetes.io/alibaba-cloud-loadbalancer-spec: "slb.spec.s1.small"
spec:
rules:
- host: foo.bar.com # Replace with your domain name
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: nginx-service # Backend service name
port:
number: 80 # Backend service port
tls: # Optional, for enabling HTTPS
- hosts:
- foo.bar.com # Replace with your domain name
secretName: tls-secret # TLS certificate Secret nameÉtapes suivantes
Pour les applications nécessitant un stockage persistant, telles que les bases de données, utilisez plutôt un StatefulSet. Consultez la section Créer une charge de travail avec état (StatefulSet).
Si vous rencontrez des problèmes lors de la création d'une charge de travail, consultez la section FAQ sur les charges de travail.
Si un pod est dans un état anormal, consultez la section Résoudre les exceptions de pod.