Usage notes and instructions on high-risk operations - Container Compute Service

Container Compute Service (ACS) fournit des architectures gérées et des composants clés pour le calcul conteneurisé. Des opérations inappropriées sur des composants ou applications non gérés au sein des clusters ACS peuvent entraîner des interruptions de service. Afin d'anticiper et d'éviter ces risques, assurez-vous de lire et de comprendre les recommandations ainsi que les remarques d'utilisation présentées dans cette rubrique avant de commencer à utiliser ACS.

Remarques d'utilisation

Mises à jour du cluster

Utilisez la fonctionnalité de mise à jour de cluster d'ACS pour mettre à niveau les versions Kubernetes de vos clusters ACS. Le recours à d'autres méthodes est susceptible de provoquer des problèmes de stabilité ou de compatibilité.

ACS propose les fonctionnalités suivantes pour prendre en charge les mises à jour de cluster :

Mises à jour de version pour les clusters ACS.
Pré-vérifications avant la mise à jour. Ces contrôles permettent de s'assurer que le cluster ACS remplit les conditions requises pour la mise à jour de version.
Notes de version pour les nouvelles versions Kubernetes. Elles décrivent les nouveautés et comparent les nouvelles versions aux précédentes.
Notifications concernant les risques potentiels liés aux modifications de ressources. Cette fonctionnalité vous informe des risques pouvant découler des changements de ressources induits par les mises à jour de version.

Il est recommandé de suivre ces conseils lors de l'utilisation de la fonctionnalité de mise à jour de cluster :

Effectuez une pré-vérification avant de mettre à jour le cluster et corrigez les problèmes signalés dans le rapport de pré-vérification.
Lisez attentivement les notes de version des nouvelles versions Kubernetes. Vérifiez l'état de votre cluster et de vos charges de travail en fonction des risques de mise à jour signalés par ACS, puis évaluez l'impact de la mise à jour du cluster.
Les mises à jour de cluster ne peuvent pas être annulées. Avant toute mise à jour, préparez l'opération et définissez un plan de sauvegarde.
Mettez à jour votre cluster vers la dernière version Kubernetes avant que celle-ci ne soit dépréciée par ACS. Pour plus d'informations, consultez Versions Kubernetes prises en charge.

Configurations Kubernetes

N'utilisez pas d'annotations réservées par Kubernetes dans vos modèles YAML. Cela pourrait entraîner une indisponibilité des ressources, des échecs d'applications ou des exceptions. Les libellés préfixés par kubernetes.io/ ou k8s.io/ sont réservés aux composants clés. Exemple : pv.kubernetes.io/bind-completed: "yes".

Clusters ACS

Dans le scénario suivant, les clusters ACS ne sont pas éligibles à une indemnisation :

Afin de simplifier l'exploitation et la maintenance du cluster, ACS peut gérer certains composants système à votre place. Une fois les composants système gérés activés pour votre cluster, ACS se charge de leur déploiement et de leur maintenance. Aucune indemnisation n'est accordée pour les pertes commerciales résultant d'erreurs utilisateur, telles que la suppression accidentelle de ressources Kubernetes utilisées par ces composants gérés.

Opérations à haut risque

Les opérations suivantes sont considérées comme à haut risque dans ACS et peuvent compromettre gravement la stabilité de votre activité. Prenez connaissance des impacts associés à chacune de ces opérations.

Opérations à haut risque sur les clusters

Catégorie

Opération à haut risque

Impact

Procédure de récupération

API Server

Supprimer l'instance Server Load Balancer (SLB) utilisée pour exposer l'API server.

La gestion du cluster devient impossible.

Irrécupérable. Vous devez créer un nouveau cluster.

Autres

Modifier les permissions via Resource Access Management (RAM).

Échec possible de la création de ressources telles que les instances SLB.

Rétablissez les permissions initiales.

Opérations à haut risque sur les réseaux et l'équilibrage de charge

Opération à haut risque	Impact	Procédure de récupération
Modifier ou supprimer les tags ajoutés par ACS aux instances SLB.	Fonctionnement anormal des instances SLB.	Rétablissez les tags d'origine.
Modifier les configurations des instances SLB gérées par ACS, y compris les paramètres des instances, des écouteurs et des groupes vServer.	Fonctionnement anormal des instances SLB.	Restaurez la configuration SLB.
Retirer l'annotation `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: ${YOUR_LB_ID}`, servant à désigner une instance SLB existante, de la configuration du Service.	Dysfonctionnement de l'instance SLB existante.	Ajoutez l'annotation à la configuration du Service. Remarque Si un Service est configuré pour utiliser une instance SLB existante, il est impossible de modifier cette configuration afin de créer une nouvelle instance SLB pour ce même Service. Pour utiliser une nouvelle instance SLB, vous devez créer un nouveau Service.
Supprimer directement depuis la console SLB les instances créées par ACS.	Risques d'erreurs réseau au niveau du cluster.	Supprimez les instances SLB en supprimant les Services qui y sont associés. Pour plus d'informations sur la suppression d'un Service, consultez Supprimer un Service.
Supprimer manuellement le Service `nginx-ingress-lb` dans le namespace kube-system d'un cluster où le contrôleur NGINX Ingress est installé.	Le contrôleur NGINX Ingress ne fonctionne plus correctement et risque de s'arrêter.	Créez un Service portant le même nom à l'aide du modèle YAML suivant : `apiVersion: v1 kind: Service metadata: annotations: labels: app: nginx-ingress-lb name: nginx-ingress-lb namespace: kube-system spec: externalTrafficPolicy: Local ports: - name: http port: 80 protocol: TCP targetPort: 80 - name: https port: 443 protocol: TCP targetPort: 443 selector: app: ingress-nginx type: LoadBalancer`

Opérations à haut risque sur le stockage

Opération à haut risque	Impact	Procédure de récupération
Démonter des disques des pods via la console Elastic Compute Service (ECS).	Des erreurs d'E/S surviennent lors de l'écriture de données dans les pods.	Redémarrez les pods concernés.
Monter un même disque sur plusieurs pods.	Les données du pod sont écrites sur des disques locaux ou des erreurs d'E/S se produisent lors de l'écriture.	Montez le disque sur un seul pod. Important Les disques Alibaba Cloud ne peuvent pas être partagés. Chaque disque ne peut être monté que sur un seul pod.
Supprimer manuellement les répertoires File Storage NAS (NAS) montés sur des pods.	Des erreurs d'E/S surviennent lors de l'écriture de données dans les pods.	Redémarrez les pods concernés.

Opérations à haut risque sur les journaux

Opération à haut risque

Impact

Procédure de récupération

Supprimer les CustomResourceDefinitions (CRDs) aliyunlogconfig.

Échec de la collecte des journaux.

Recréez les CRDs aliyunlogconfig supprimés ainsi que les ressources associées. Les journaux générés pendant la période d'absence des CRDs aliyunlogconfig ne peuvent pas être collectés.

La suppression des CRDs aliyunlogconfig entraîne également celle des tâches de collecte de journaux associées. Après avoir recréé les CRDs, vous devez relancer ces tâches de collecte.

Désinstaller les composants de journalisation.

Échec de la collecte des journaux.

Réinstallez les composants de journalisation et recréez manuellement les CRDs aliyunlogconfig. Les journaux générés durant l'indisponibilité des composants de journalisation ne peuvent pas être récupérés.

La suppression des composants de journalisation efface aussi les CRDs aliyunlogconfig et Logtail. Toute donnée journalisée pendant cette période d'inactivité est perdue.