Déployer Oracle Kubernetes Engine (OKE) pour la production : meilleures pratiques et directives

Introduction

Il s'agit du troisième tutoriel de notre série d'automatisation Oracle Cloud Infrastructure Kubernetes Engine (OKE), qui s'appuie sur les concepts présentés dans le deuxième tutoriel, Déploiement d'Oracle Cloud Infrastructure Kubernetes Engine (OKE) à l'aide de modules Terraform avancés. Dans ce guide, nous mettons l'accent sur les déploiements OKE prêts à l'emploi et explorons les meilleures pratiques clés qui améliorent la fiabilité des clusters, optimisent les coûts et simplifient les opérations. Nous présenterons certaines des meilleures pratiques d'utilisation de Terraform tout en mettant en évidence les pièges courants rencontrés par les utilisateurs lors de la création de clusters.

Pourquoi le déploiement d'OKE dans un VCN existant est important

La création d'un cluster OKE de qualité production nécessite une planification minutieuse des processus de mise en réseau, de positionnement des noeuds et opérationnels. Le déploiement dans un réseau cloud virtuel (VCN) existant permet à votre cluster de s'intégrer de manière transparente à des sous-réseaux, des tables de routage et des règles de sécurité préconfigurés. Cela réduit les frais opérationnels, garantit la cohérence avec l'infrastructure de votre entreprise et permet à plusieurs charges de travail ou clusters de coexister efficacement au sein du même réseau.

Les paramètres clés de Terraform lors du déploiement dans un VCN existant sont les suivants :

Lors du déploiement d'un nouvel environnement à partir de zéro, vous pouvez également définir is_vcn_created = true pour provisionner un nouveau réseau. Après une opération terraform apply réussie, Terraform capture les OCID du VCN nouvellement créé et de ses sous-réseaux dans les sorties. Ces valeurs peuvent être réutilisées dans des déploiements futurs en définissant is_vcn_created = false et en référençant les OCID enregistrés dans votre fichier terraform.tfvars, ce qui permet à Terraform d'utiliser le réseau existant au lieu d'en créer un. L'exécution de terraform plan à ce stade confirme que le VCN et les sous-réseaux en cours sont conservés, ce qui évite toute modification inutile de l'infrastructure.

Avec la base du réseau en place, ce tutoriel se concentre sur un ensemble de bonnes pratiques orientées production visant à rendre les clusters OKE plus résilients, évolutifs et plus faciles à utiliser. En appliquant ces pratiques, les clients peuvent déployer des clusters OKE hautement disponibles, rentables et alignés sur les politiques organisationnelles, les normes de gouvernance et les exigences opérationnelles prêtes à l'emploi. Téléchargez le dernier code à partir d'ici oke_advanced_module.zip.

Meilleures pratiques OKE : Directives prêtes pour la production

1. Utilisez le cyclage de noeud pour mettre à niveau les pools de noeuds OKE.

Le cyclage de noeud est une stratégie de mise à niveau non simultanée sûre qui met à jour les images de noeud, les versions de Kubernetes ou les configurations système sans interrompre les charges de travail. Le cyclage des noeuds est important car il permet aux clusters d'évoluer en toute sécurité au fil du temps, en appliquant des patches ou des mises à niveau sans affecter les charges de travail de production. Pour les clients, cela réduit les risques opérationnels, garantit une disponibilité continue pendant les mises à niveau et permet aux charges de travail de s'exécuter de manière fiable tout en conservant les dernières versions. OKE prend en charge deux types :

Des paramètres tels que maximum_surge et maximum_unavailable contrôlent l'équilibre entre la vitesse et la disponibilité des mises à niveau. Pour les mises à niveau sans temps d'arrêt, définissez maximum_surge = 1 et maximum_unavailable = 0, en veillant à ce qu'un nouveau noeud soit mis en ligne avant de remplacer l'ancien. L'exemple suivant illustre un cycle de nœud avec la surtension Max 1 et la surtension Max indisponible 0.

OKENodepoolupgraded

Pour déclencher la mise à niveau d'un cluster OKE existant qui entraîne le cyclage des noeuds :

Dans le fichier terraform.tfvars :

Exécutez ensuite terraform plan.

Une sortie semblable à la suivante doit s'afficher :

Lorsque vous exécutez terraform apply, OKE commence à cycler les pools de noeuds un noeud à la fois à l'aide de la stratégie BOOT_VOLUME_REPLACE. Dans ce mode, seul le volume d'initialisation du noeud est remplacé alors que l'instance de calcul sous-jacente reste la même. Par conséquent, la mise à niveau du noeud est effectuée en place et les attributs réseau tels que l'adresse IP privée restent inchangés comme suit :

OKEclusterUpgrading OKEclusterUpgrading OKEclusterUpgrading

Pour cycler les noeuds à l'aide de l'option INSTANCE_REPLACE, définissez cycle_modes sur INSTANCE_REPLACE pour OKE afin de cycler les pools de noeuds un noeud à la fois. Dans ce mode, chaque noeud est supprimé et recréé de toutes pièces, y compris l'instance de calcul et son volume d'initialisation. Par conséquent, la mise à niveau de noeud applique tous les attributs mis à jour, tels qu'une nouvelle version de Kubernetes ou des modifications de forme, mais les attributs réseau tels que l'adresse IP privée peuvent changer. Cette approche garantit un noeud entièrement actualisé avec les dernières configurations, offrant une couverture maximale des mises à jour tout en maintenant la disponibilité du cluster via des remplacements non simultanés, comme indiqué ci-dessous :

OKEclusterUpgrading OKEclusterUpgrading

2. Utiliser le balisage OCI sur les noeuds de processus actifs OKE et les équilibreurs de charge pour suivre les coûts

Lors de l'exécution de charges de travail Kubernetes dans Oracle Cloud Infrastructure (OCI), il est essentiel de comprendre d'où proviennent vos coûts. Le balisage est la clé. OCI vous permet d'appliquer des balises définies et à format libre à chaque ressource, y compris les clusters OKE, les noeuds de processus actif, les équilibreurs de charge et les volumes persistants. Ceci est important car il permet un reporting détaillé des coûts, un audit plus facile et une responsabilisation pour la consommation du cloud. Pour les clients, le balisage fournit des informations sur les charges de travail qui consomment le plus de ressources, améliore la transparence des coûts et prend en charge les décisions d'optimisation pour contrôler les dépenses cloud.

Pourquoi le balisage est important :

# Cluster-level tagging
cluster_freeform_tag_key   = "Environment"
cluster_freeform_tag_value = "Development"

# Node pool-level tagging
node_pool_freeform_tag_key   = "LOB"
node_pool_freeform_tag_value = "DevOps Tech"

# Bastion host tagging
freeform_tags = {
  project     = "devops"
  environment = "production"}

# Defined tagging
defined_tags = { 
  “Corporate_Standard.CostCenter”  = “Finance-123"
  “Corporate_Standard.Environment” = “Production” }

Avec ces balises en place, vous pouvez générer des rapports détaillés sur les coûts dans OCI Cost Analysis, identifier les charges de travail qui consomment le plus de ressources et prendre des décisions éclairées sur l'évolutivité ou l'optimisation.

3. Des adresses d'API, des noeuds, des équilibreurs de charge et des sous-réseaux de pod distincts (le cas échéant).

Une conception de réseau appropriée est une bonne pratique dans OKE car elle améliore la sécurité, les performances et l'évolutivité. La séparation des adresses d'API, des noeuds de processus actif, des pods, des équilibreurs de charge et des hôtes de bastion en sous-réseaux distincts isole le trafic critique, permet de personnaliser les tables de routage ou les groupes de sécurité réseau et empêche un type de trafic d'interférer avec un autre. Cette approche est essentielle pour maintenir une communication sécurisée, un routage prévisible et une forte isolation des ressources dans les environnements de production.

Les clients bénéficient d'un cluster plus sécurisé, gérable et résilient qui peut évoluer efficacement et gérer les pics de trafic ou les attaques sans impact sur les charges de travail. Voici le fragment de code de terrform.tfvars qui vous permet de définir des blocs CIDR pour les sous-réseaux.

k8apiendpoint_private_subnet_cidr_block       = "REPLACE_WITH_YOUR_CIDR"   # API endpoint subnet
workernodes_private_subnet_cidr_block         = "REPLACE_WITH_YOUR_CIDR"   # Worker nodes subnet
pods_private_subnet_cidr_block                = "REPLACE_WITH_YOUR_CIDR"   # Pod subnet (CNI)
serviceloadbalancers_public_subnet_cidr_block = "REPLACE_WITH_YOUR_CIDR"   # Load balancer subnet
bastion_public_subnet_cidr_block              = "REPLACE_WITH_YOUR_CIDR"   # Bastion host subnet

En suivant cet exercice, vous allez améliorer la sécurité, simplifier la gestion du réseau et rendre votre cluster plus résilient face aux pics de trafic ou aux attaques.

4. Utiliser un pool de noeuds par architecture de domaine de disponibilité lors de l'utilisation de l'outil de redimensionnement automatique de cluster

Dans OCI, chaque domaine de disponibilité dispose d'une capacité indépendante. Bien que les pools de noeuds puissent s'étendre sur plusieurs domaines de disponibilité pour améliorer la haute disponibilité, cela n'est pas recommandé lorsque l'outil de redimensionnement automatique de cluster est activé. L'outil de redimensionnement automatique requiert de la capacité dans tous les domaines de disponibilité sélectionnés et peut échouer si un domaine de disponibilité manque de ressources.

Pour éviter cela, les pools de noeuds doivent être configurés pour utiliser un seul domaine de disponibilité lorsque le redimensionnement automatique est activé. Si la capacité n'est pas disponible dans un domaine de disponibilité, l'outil de redimensionnement automatique peut redimensionner un autre pool de noeuds dans un autre domaine de disponibilité.

Exemple de configuration de pool de noeuds :

availability_domains = [
      "REPLACE_WITH_YOUR_AD"
    ]

Exemple de configuration d'autoscaler de cluster :

cluster_autoscaler_config = {
  node_mapping = {
    key = "nodes"
    value = "1:5:ocid1.nodepool....."
  }
}

5. Pools de noeuds distincts pour différentes exigences en matière de charge globale (x86, ARM, GPU)

Utilisez des pools de noeuds distincts pour les charges globales nécessitant différentes formes de calcul, telles que x86, ARM ou GPU. Cette approche améliore l'utilisation des ressources, l'efficacité de la planification et le comportement de redimensionnement automatique en veillant à ce que chaque charge de travail s'exécute sur l'infrastructure la plus appropriée.

Les pods sont programmés vers les pools de noeuds appropriés à l'aide d'étiquettes, de sélecteurs, d'affinités ou de tolérances de noeud, ce qui permet à Kubernetes de placer des charges globales sur des noeuds dotés de l'architecture ou des fonctionnalités requises.

En associant des pools de noeuds dédiés à un placement explicite de pod, les clients bénéficient de performances prévisibles, d'une mise à l'échelle efficace et d'une gestion simplifiée des clusters. Dans cet exemple, des pools de noeuds distincts sont créés pour les formes Intel et AMD, ce qui garantit un placement optimal des charges de travail et des opérations de cluster résilientes.

worker_node_pools = {
  AMD_node_pool = {
    name               = "node_pool_one"                # Node pool name
    shape              = "VM.Standard.E5.Flex"          # Compute shape
    shape_config = {
      memory = 16                                       # Memory (GB)
      ocpus  = 1                                        # OCPUs
    }
    boot_volume_size   = 50                             # Boot volume size (GB)
    operating_system   = "Oracle-Linux"                 # OS for worker nodes
    kubernetes_version = "v1.33"                        # Node Kubernetes version
    source_type        = "IMAGE"                        # Source type for image
    node_labels = {
      Trigger = "Nodes_Cycling_0"                       # Node label
    }
    availability_domains = [                            # Availability_domain setting
      "REPLACE_WITH_YOUR_AD"
    ]                                                   # ADs for node distribution
    number_of_nodes          = 1                        # Number of worker nodes
    pv_in_transit_encryption = false                    # Boot volume in-transit encryption
    node_cycle_config = {
      node_cycling_enabled = true                       # Enable node cycling by default
      maximum_surge        = 1                          # Number of surge nodes
      maximum_unavailable  = 0                          # Max unavailable nodes
      cycle_modes          = ["BOOT_VOLUME_REPLACE"]    # cycle_modes"BOOT_VOLUME_REPLACE" or "INSTANCE_REPLACE"

    }
    ssh_key = "REPLACE_WITH_YOUR_KEY"                   # SSH public key for workers nodes
  }
  Intel_node_pool = {
    name               = "node_pool_two"                # Node pool name
    shape              = "VM.Standard2.8"      	        # Compute shape
    shape_config = {
      memory = 120                                      # Memory (GB)
      ocpus  = 8                                        # OCPUs
    }
    boot_volume_size   = 50                             # Boot volume size (GB)
    operating_system   = "Oracle-Linux"                 # OS for worker nodes
    kubernetes_version = "v1.33"                        # Node Kubernetes version
    source_type        = "IMAGE"                        # Source type for image
    node_labels = {
      Trigger = "Nodes_Cycling_0"                       # Node label
    }
    availability_domains = [                            # Availability_domain setting
      "REPLACE_WITH_YOUR_AD"  
    ]                                                   # ADs for node distribution
    number_of_nodes          = 1                        # Number of worker nodes
    pv_in_transit_encryption = false                    # Boot volume in-transit encryption
    node_cycle_config = {
      node_cycling_enabled = true                       # Enable node cycling by default
      maximum_surge        = 1                          # Number of surge nodes
      maximum_unavailable  = 0                          # Max unavailable nodes
      cycle_modes          = ["BOOT_VOLUME_REPLACE"]    # cycle_modes"BOOT_VOLUME_REPLACE" or "INSTANCE_REPLACE"

    }
    ssh_key = "REPLACE_WITH_YOUR_KEY"                   # SSH public key for workers nodes
  }

}

Après l'exécution de terraform apply, le cluster OKE affiche deux pools de noeuds distincts :

OKEtwonodepools OKEIntelnodepool OKEAMDnodepool

6. Utiliser Cloud-Init pour la personnalisation des noeuds

Les scripts Cloud-init sont essentiels pour automatiser la configuration des noeuds de processus actif dans OKE, ce qui garantit la cohérence de la configuration du système d'exploitation, de l'installation des packages et du réglage du système sur tous les noeuds. L'intégration de cloud-init à Terraform vous permet de provisionner des noeuds automatiquement au démarrage, ce qui permet de répéter les déploiements, de les auditer et de les préparer à la production. Consultez ce document Utilisation de scripts d'initialisation cloud-init personnalisés pour configurer des noeuds gérés pour plus d'informations sur les scripts cloud-init.

Dans le code Terraform fourni, chaque pool de noeuds référence un script cloud-init à l'aide du paramètre cloud_init_path. Les clients peuvent modifier le contenu de cloud-init-general.sh en fonction de leurs besoins, conformément aux directives du document ci-dessus. Dans cette démonstration, nous utilisons le script de démarrage par défaut fourni dans la documentation référencée. Les clients peuvent également modifier l'emplacement du script cloud-init en mettant à jour le paramètre cloud_init_path, comme indiqué ci-dessous :

cloud_init_path = "cloud-init-general.sh"

Cela garantit que lors du provisionnement ou du cyclage des noeuds, chaque noeud nouveau ou remplacé est initialisé conformément à la configuration système requise. Associé à Terraform, cloud-init permet l'application automatique de scripts gérés par version, ce qui élimine les tâches manuelles de post-provisionnement.

Principaux avantages pour les noeuds de processus actifs :

7. Améliorer la fonctionnalité OKE à l'aide d'extensions

Les modules complémentaires OKE étendent les fonctionnalités de cluster pour l'observabilité, la mise à l'échelle, la sécurité et la gestion du trafic. Avec Terraform, vous pouvez activer ou désactiver des modules complémentaires en fonction des exigences de charge de travail et de l'utilisation minimale des ressources :

kubernetes_dashboard_enabled       = false
metrics_server_enabled             = false
cluster_autoscaler_enabled         = false
certificate_manager_enabled        = false
istio_enabled                      = false
native_ingress_controller_enabled  = false

Modules courants et leurs avantages :

Meilleures pratiques pour les modules :

8. Utilisez l'authentification/la détection OIDC si des ressources externes ont besoin d'accéder aux clusters k8s.

Intégrez la découverte OIDC avec des fournisseurs d'identités externes (tels que Okta ou Azure AD) si les développeurs ou les outils d'automatisation en dehors d'OCI doivent s'authentifier auprès de votre cluster Kubernetes. Cela permet une gestion centralisée des identités et un accès fédéré sans avoir à gérer les utilisateurs Kubernetes locaux ni à distribuer les fichiers kubeconfig. Cette approche est particulièrement utile lorsque des outils d'intégration continue et de déploiement continu externes tels que GitHub Actions ont besoin d'accéder au cluster ou lorsque les charges globales au sein du cluster doivent s'intégrer en toute sécurité à des services externes tels que HashiCorp Vault. En s'appuyant sur OIDC, les entreprises peuvent appliquer des stratégies d'authentification cohérentes, simplifier la gestion des accès et réduire la surcharge opérationnelle liée à la rotation des informations d'identification tout en maintenant de fortes limites de sécurité.

9. Utiliser des groupes de sécurité réseau au lieu des listes de sécurité

Les groupes de sécurité réseau (NSG) sont préférés aux listes de sécurité traditionnelles lors de la sécurisation des clusters OKE. Les groupes de sécurité réseau permettent des règles de sécurité plus détaillées, flexibles et réutilisables qui peuvent être attachées directement à des ressources spécifiques telles que des noeuds de processus actifs, des équilibreurs de charge ou des pods. Cela les rend mieux adaptés aux environnements Kubernetes dynamiques où les ressources évoluent ou changent fréquemment. En revanche, les listes de sécurité s'appliquent au niveau du sous-réseau et sont conçues pour englober des réseaux cloud virtuels ou des sous-réseaux entiers, ce qui offre moins de contrôle lors de l'implémentation d'exigences de sécurité d'application détaillées. L'utilisation de groupes de sécurité réseau améliore l'hygiène de sécurité, simplifie la gestion des règles et permet une isolation plus étroite entre les composants du cluster.

10. Activer l'observabilité avec OCI Logging Analytics et les mesures OKE

Intégrez OKE à OCI Logging Analytics et Monitoring pour bénéficier d'une visibilité approfondie sur les performances des clusters et des workloads. Logging Analytics fournit une agrégation de journaux avancée, une analyse et une détection d'anomalies, tandis que Monitoring collecte des mesures à partir du plan de contrôle Kubernetes et des noeuds de processus actif. Ensemble, ces services permettent aux équipes de visualiser les tendances, de résoudre les problèmes plus rapidement et de configurer des alertes pour une gestion proactive. Cette solution est particulièrement adaptée aux clients à la recherche d'une plate-forme d'observabilité native OCI qui élimine les complexités de l'ingestion, du stockage et de l'analyse des journaux, tout en s'intégrant de manière transparente à d'autres services OCI.

11. Utilisez l'identité de charge globale si les pods ont besoin d'accéder aux ressources OCI.

Lors de l'authentification auprès d'OCI, les clés d'API sont couramment utilisées, mais ces informations d'identification sont de longue durée et nécessitent un stockage persistant, ce qui les rend difficiles à gérer en toute sécurité à grande échelle. Alors que les principaux d'instance et de ressource l'améliorent en permettant aux instances ou services de calcul de prendre leur propre identité, OKE Workload Identity étend ce concept davantage en permettant aux pods Kubernetes individuels d'assumer leur propre identité OCI. En activant OCI Workload Identity, les pods peuvent accéder en toute sécurité aux services OCI tels qu'Object Storage ou Logging à l'aide de stratégies IAM, sans informations d'identification de codage en dur ou en s'appuyant sur des droits d'accès au niveau du noeud. Cela permet un contrôle d'accès affiné, auditable et sécurisé, essentiel pour les environnements Kubernetes colocatifs de production.

12. Utilisez la taille de sous-réseau appropriée pour les noeuds et pods OKE.

Il est recommandé de planifier correctement les blocs CIDR de sous-réseau car chaque noeud nécessite une adresse IP principale et des adresses IP secondaires supplémentaires pour les pods. Les petits sous-réseaux peuvent rapidement entraîner l'épuisement des adresses IP, ce qui empêche la mise à l'échelle ou les mises à niveau. Ceci est important pour maintenir la stabilité des clusters et soutenir la croissance. Les clients en bénéficient en s'assurant que les clusters peuvent évoluer de manière prévisible, en évitant les perturbations opérationnelles et en prenant en charge les charges de travail futures sans nécessiter de refonte du réseau. Pour les environnements de production, allouez des blocs CIDR plus volumineux et reportez-vous au guide de dimensionnement du sous-réseau OKE afin de vous assurer que votre VCN peut prendre en charge les demandes de charge globale actuelles et futures.

13. Utiliser le service Full Stack Disaster Recovery pour sauvegarder le cluster k8s

L'utilisation d'OCI Full Stack Disaster Recovery pour le cluster OKE est une bonne pratique car elle protège la configuration du cluster, les applications et le réseau avec un basculement et un rétablissement coordonnés entre les régions. Ceci est important pour la continuité des activités et la conformité en cas de pannes régionales ou de pannes système. Les clients bénéficient d'une réduction des temps d'arrêt, d'une récupération rapide et de la confiance que les charges de travail critiques restent opérationnelles même en cas de sinistre.

Pour plus d'informations, consultez Automatiser les plans de permutation et de basculement pour OCI Kubernetes Engine (avec conservation de statut) avec OCI Full Stack Disaster Recovery

Etapes suivantes:

Terraform rend le provisionnement OKE cohérent, automatisé et évolutif. En suivant les meilleures pratiques telles que le balisage OCI, la séparation des sous-réseaux et la configuration de nœuds standardisés, vos clusters restent sécurisés, organisés et transparents en termes de coûts. Dans le prochain blog, nous allons nous appuyer sur ces bases pour explorer les opérations basées sur l'IA, montrer comment intégrer Oracle AIOps, activer l'observabilité basée sur l'IA et créer un modèle OKE de bout en bout pour les workloads d'IA. Restez à l'affût de notre prochaine session LiveLabs, au cours de laquelle vous pourrez vous familiariser avec ces techniques et expérimenter les déploiements OKE dans un environnement actif.

Accusés de réception

Ressources de formation supplémentaires

Explorez d'autres ateliers sur le site docs.oracle.com/learn ou accédez à d'autres contenus d'apprentissage gratuits sur le canal Oracle Learning YouTube. En outre, visitez le site education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour obtenir de la documentation sur le produit, consultez Oracle Help Center.