Le développement peut être comparé à une image où l'artiste est un développeur de premier plan. Création d'une élégante application de microservices - avec les créations des meilleurs architectes - modernistes. Mais pour mettre le processus en marche et laisser la possibilité de choisir - l'art. Dans le premier article de la série, nous voulons parler de la façon dont le service IBM Kubernetes et le service cloud IBM Managed OpenShift ont été créés et exécutés, et comment vous pouvez déployer et tester gratuitement votre cluster Kubernetes dans le cloud IBM.
Le cloud IBM a gagné en fonctionnalité au cours des dix dernières années. Tout a commencé avec la construction d'infrastructures partagées pour desservir les grandes entreprises, puis avec des machines virtuelles et physiques basées sur les centres de données SoftLayer, puis il y a eu la construction de PaaS (basée sur les temps d'exécution de Cloud Foundry) sur cinq ans et l'évolution d'un grand nombre de services. L'équipe de développement de Moscou a également participé à la création d'une partie des services. Mais aujourd'hui, nous ne parlons pas de services, mais de ce qui est géré kubernetes et managed openshift et comment cela fonctionne dans le cloud IBM. De nombreux détails ne peuvent être révélés, car le projet est interne, mais il est possible d'ouvrir un certain rideau.
Qu'est-ce que kubernetes et comment est-il géré kubernetes / openshift différent d'une installation locale
Kubernetes était initialement positionné comme une plate-forme open source pour la gestion des applications et services conteneurisés. Les tâches principales de kubernetes sont (je partirai sans traduction, afin de ne pas casser la terminologie):
- Découverte de services et équilibrage de charge
- Orchestration du stockage
- Déploiements et restaurations automatisés
- Emballage automatique du bac
- Auto-guérison
- Gestion du secret et de la configuration
En général, kubernetes fait un excellent travail de toutes ces tâches. D'autre part, kubernetes a commencé à se positionner comme une base de données pour le stockage des configurations d'application ou un outil API pour la gestion de vos composants (particulièrement pertinent dans le cadre du développement des opérateurs).
L'un des avantages de kubernetes est que vous pouvez exécuter des applications conteneurisées à la fois sur vos ressources informatiques et dans le cloud. Dans le cas des ressources cloud - de nombreux fournisseurs de cloud offrent la possibilité d'utiliser des ressources informatiques pour exécuter des applications et prendre en charge l'administration complète des clusters:
- déploiement de cluster
- définition de la disponibilité et de la distribution du réseau
- installation de mises à jour et de correctifs
- Configurer un cluster pour augmenter la tolérance aux pannes et la sécurité (plus dans l'article)
- ...
Si vous travaillez avec des kubernetes gérés dans n'importe quel cloud, vous êtes bien sûr limité dans un certain nombre d'actions. Par exemple, plusieurs versions de kubernetes sont généralement prises en charge, et il est peu probable que vous puissiez utiliser des versions de kubernetes qui n'ont pas été prises en charge depuis longtemps. Le principal avantage est sans aucun doute que ce n'est pas votre équipe qui administre les clusters, ce qui réduit le temps nécessaire au développement d'applications. Bien sûr, les kubernetes gérés et les openshift gérés ne peuvent pas être utilisés dans toutes les organisations et pour tout type d'application, mais il existe un large éventail de tâches qui sont idéales pour l'informatique dans les nuages.
Architecture cloud
Au sein de l'entreprise, le projet IBM Managed Kubernetes et le projet IBM Managed OpenShift sont appelés le projet Armada. Le projet a commencé avec un seul centre de données, mais il est maintenant disponible dans 60 centres de données cloud dans 6 régions différentes. Afin de décrire l'évolution du nuage, j'utiliserai deux termes: moyeux et rayons. L'ensemble du projet Armada est basé sur kubernetes, ce qui signifie que ses clusters sont contrôlés par un panneau de contrôle qui fonctionne sur kubernetes. Dès que le panneau de contrôle ne dispose pas de suffisamment de ressources pour gérer l'ensemble nécessaire de clusters, il déploie des rayons supplémentaires. Ces rayons continueront d'être responsables de la gestion des clusters dans une région spécifique.
Le panneau de contrôle comprend plus de 1 500 déploiements et est situé dans 60 clusters kubernetes. Tout cela est nécessaire pour gérer plus de 15 000 clusters de nos clients (hors test des clusters gratuits qui sont déployés sur le même travailleur).
Pour créer IKS et Managed OpenShift, l'équipe a utilisé le modèle OpenSource en interne. La plupart des employés IBM ont accès à la plupart des référentiels Armada et peuvent créer leurs propres RP pour intégrer leurs services. Dans le cadre du travail de service, un grand nombre d'outils CI / CD ont également été développés, qui ont été intégrés dans le projet Razee. À l'été 2019, IBM a téléchargé toutes les réalisations du projet Razee sur OpenSource.
En général, l'architecture d'IKS et de Managed OpenShift est la suivante:
Lorsque vous travaillez avec IBM Cloud CLI et demandez la création d'un cluster, en fait vos demandes vont à l'API Armada, puis le panneau de contrôle détermine la disponibilité des rayons et lance la création du nombre requis de travailleurs dans les régions que vous spécifiez. L'infrastructure entière pour les travailleurs est fournie en utilisant IBM Cloud Infrastructure (aka Soflayer), en fait, les mêmes instances virtuelles et hôtes bare metal sont utilisés, qui sont disponibles dans la section "Calculer" du catalogue des services cloud. Après un certain temps, vous recevrez un jeton d'autorisation et vous pourrez commencer à déployer vos applications.
Étant donné qu'OpenShift et Kubernetes diffèrent dans leurs capacités et leur feuille de route de développement, la pile technologique sous-jacente est également différente:
Comment la sécurité est-elle assurée?
On peut parler du projet Armada très longtemps tant du point de vue technique que du marketing. Mais tout d'abord, lors du choix d'un fournisseur de cloud qui fournit des kubernetes gérés, tout le monde pose la même question - comment le fournisseur garantit-il et garantit-il la sécurité et la tolérance aux pannes de mes applications? ... Il est impossible d'évaluer les performances, la commodité, le niveau de support technique sans recevoir de réponse à cette question. En tant que responsable du développement, lors du développement de tout projet majeur, je dessine une carte des menaces. Il est nécessaire d'y introduire toutes les options de piratage possibles et de sécuriser votre infrastructure, vos applications et vos données. Afin de parler de la sécurité du cluster kubernetes, vous devez décrire les points suivants:
- sécurité de l'infrastructure elle-même et des centres de données
- accès à Kubernetes API et etcd
- nœuds maître et travailleur de sécurité
- sécurité du réseau
- sécurité persistante du stockage
- surveillance et journalisation
- sécurité des conteneurs et images de conteneurs
Maintenant, tout d'abord:
Sécurité de l'infrastructure elle-même et des centres de données
Quelle que soit la façon dont nous souhaitons nous désengager complètement du matériel et de la maintenance du bourrage matériel des systèmes informatiques, en fait, nous devons être sûrs que le fournisseur de services couvrira complètement nos arrières et le confirmera documenté à l'aide de certifications industrielles et industrielles, et si nécessaire à l'aide de rapports sur effectuer des audits. Cet aspect a été pris en compte par l'équipe IBM avec tout le sérieux possible et toutes les informations nécessaires ont été collectées et présentées en un seul endroit ( https://www.ibm.com/cloud/compliance )
Accéder à l'API Kubernetes et etcd
Pour accéder à l'API Kubernetes et aux données dans etcd, vous devez passer par trois niveaux d'autorisation. Chaque jeton d'autorisation émis est associé à des jetons d'authentification, à des données d'autorisation de cluster (RBAC) et au contrôleur d'admission (voir le schéma ci-dessous).
Étant donné que les assistants sont configurés de manière centralisée à l'aide de rayons, cela signifie que vous ne pouvez pas modifier la configuration de l'assistant, les assistants eux-mêmes ne sont même pas situés sur votre compte cloud et ne sont pas visibles dans la liste de vos appareils (contrairement aux travailleurs). Toutes les modifications de configuration ne peuvent être effectuées que dans certaines capacités. D'une part, il s'agit d'une limitation, mais en raison de cette limitation, les attaquants n'auront également pas accès à vos assistants, en plus il n'y a pas de facteur d'erreur humaine, il n'y a aucun risque d'utiliser des versions incompatibles des composants kubernetes et l'ensemble du processus d'administration du cluster est facilité. En général, nous pouvons dire qu'IBM est chargé d'assurer la tolérance aux pannes et la configuration correcte de kubernetes master. Si votre projet a des exigences strictes pour l'utilisation de certaines versions de composants, alors à votre place, je ne regarderais pas du tout les kubernetes gérés et utiliserais ma propre installation.
Noeuds maître et travailleur de sécurité
Afin d'assurer la sécurité des travailleurs et du maître des nœuds, nous utilisons des tunnels VPN chiffrés entre les nœuds informatiques, et l'utilisateur a la possibilité de commander un travailleur avec des disques durs chiffrés. Nous utilisons également Application Armor pour restreindre l'accès des applications aux ressources au niveau du système d'exploitation. Application Armor est une extension du noyau Linux pour configurer l'accès aux ressources pour chaque application.
Lors de la création d'un cluster, après avoir choisi la configuration qui vous convient, des serveurs virtuels ou baremetal seront créés pour vous, sur lesquels seront installés les composants pour le travail de vos collaborateurs. L'utilisateur a accès au système d'exploitation du travailleur, mais uniquement lorsqu'il est connecté via un VPN de gestion, ce qui peut être utile pour le dépannage, ainsi que pour mettre à jour le système d'exploitation du travailleur lui-même. Il n'y a pas d'accès IP public via ssh, afin d'obtenir ssh à l'intérieur du conteneur dont vous avez besoin pour utiliser kubectl exec, cette connexion sera établie via le tunnel OpenVPN.
Sécurité réseau
Dans kubernetes géré et openshift, un plugin réseau Calico est utilisé comme solution de virtualisation de réseau. La sécurité du réseau est assurée par des stratégies réseau Kubernetes et Calico préconfigurées. Vos employés peuvent se trouver dans le même VLAN que toutes vos autres infrastructures dans le même centre de données, comme les machines virtuelles ordinaires et les serveurs baremetal, ainsi que les applications réseau et les systèmes de stockage, et grâce aux systèmes calico situés à l'extérieur de votre cluster, pourra communiquer via un réseau privé avec vos déploiements.
Lorsqu'un cluster avec un VLAN public est créé, le panneau de contrôle crée une ressource HostEndpoint avec l' ibm.role: worker_public pour chaque travailleur et ses interfaces réseau externes. Pour protéger les interfaces réseau externes, le panneau de contrôle appliquera toutes les stratégies par défaut Calico à tous les points de terminaison avec le ibm.role: worker_public .
Les politiques par défaut de Calico autorisent tout le trafic sortant et autorisent le trafic entrant depuis Internet vers certains composants (service Kubernetes NodePort, LoadBalancer et Ingress). Tout autre trafic est bloqué. Les stratégies par défaut ne s'appliquent pas au trafic au sein du cluster (interaction entre les pods)
Sécurité de stockage persistante
Pour la sécurité au niveau de la persistance, le chiffrement et l'autorisation de clé sont utilisés. Actuellement disponible pour IKS:
- NFS classique
- Stockage de blocs classique (iSCSI)
- Stockage en bloc VP
- Stockage d'objets cloud IBM
- SDS Porworx (utilise les disques locaux de vos propres employés)
Surveillance et journalisation
Vous pouvez utiliser IBM Cloud Monitoring ou une solution de Sysdig pour surveiller IKS. Naturellement, Prométhée n'était pas sans. Managed OpenShift utilise des outils de surveillance intégrés.
Avec les journaux eux-mêmes, les choses sont plus compliquées. Il est nécessaire de collecter des journaux de niveaux complètement différents, nous utilisons un grand nombre de nos propres solutions open source. Nous collectons et stockons les journaux suivants:
- Journaux du conteneur lui-même (STDOUT, STDERR)
- Journaux d'application (si le chemin d'accès à ceux-ci est spécifié)
- Journaux du nœud de travail
- Journaux de l'API Kubernetes
- Journaux d'entrée
- Journaux de tous les composants du système Kubernetes (espace de noms kube-system)
Pour contrôler les journaux, un service distinct est disponible: IBM Cloud Log Analysis avec LogDNA, qui vous permet d'afficher tous les journaux dans une console commune et d'analyser rétrospectivement ou en temps réel, selon le tarif. Vous pouvez créer une instance séparément dans chacune des 6 régions, puis l'utiliser pour collecter les journaux de votre cluster Kubernetes et d'autres infrastructures sur votre compte. Pour connecter ce service à votre cluster, vous devez mettre un pod avec l'agent LogDNA en suivant des instructions simples, et tous les journaux seront envoyés au référentiel LogDNA, puis, selon le plan choisi, ils seront disponibles pour une analyse plus approfondie pendant une certaine période.
Pour analyser les activités à l'intérieur de vos services cloud, y compris les connexions et bien plus encore, Activity Tracker avec LogDNA est disponible - il vous permet de suivre diverses actions dans vos services.
En tant qu'outil de surveillance supplémentaire, vous pouvez configurer IBM Cloud Monitoring avec Sysdig sur votre cluster - il est disponible dans les 6 régions, ce qui vous permettra de surveiller de nombreuses métriques de votre cluster en temps réel et d'utiliser les intégrations intégrées avec de nombreux environnements courants exécutés dans des conteneurs. De plus, vous pouvez configurer la réaction aux événements avec la possibilité de notifications via slack, email, PagerDuty, WebHook, etc.
Sécurité des conteneurs et de l'image des conteneurs
La société a sa propre opinion sur ce qui est inclus dans DevOps. Si quelqu'un est intéressé, vous pouvez en savoir plus à ce sujet dans la méthode IBM Garage . Comprendre ce que DevSecOps est également formé dans de nombreuses entreprises et appliqué dans la pratique. Pour comprendre les étapes par lesquelles une image Docker passe pour devenir un conteneur Docker, jetez un œil à la figure suivante.
Dans le cloud IBM, il est possible d'utiliser le registre Docker en tant que service. Lors de l'envoi d'une image à ce docker de registre, l'image est signée. Du côté du nœud de travail, un addon est installé, qui est chargé de vérifier l'intégrité et la conformité aux politiques de sécurité - Vulnerability Advisor. En utilisant ces politiques, vous pouvez, par exemple, limiter le cercle de registre, d'où il est possible de télécharger des images de docker.
apiVersion: securityenforcement.admission.cloud.ibm.com/v1beta1 kind: ClusterImagePolicy metadata: name: ibmcloud-default-cluster-image-policy spec: repositories: # CoreOS Container Registry - name: "quay.io/*" policy: # Amazon Elastic Container Registry - name: "*amazonaws.com/*" policy: # IBM Container Registry - name: "registry*.bluemix.net/*" policy
Vulnerability Advisor fonctionne avec des conteneurs en cours d'exécution, en les analysant périodiquement et en détectant automatiquement les packages installés. Les images Docker présentant des vulnérabilités potentielles sont marquées comme dangereuses à utiliser et fournissent des informations détaillées sur les vulnérabilités trouvées.
Le conseiller en sécurité est le centre de gestion de toutes les vulnérabilités de votre application. Il permet de travailler avec des problèmes et de les résoudre. Il fonctionne à la fois avec les résultats de Vulnerability Advisor et avec le cluster lui-même, avertissant en temps opportun de la nécessité de mettre à jour un composant particulier.
Exemple d'enregistrement et de déploiement d'un cluster géré de kubernetes
Vous pouvez déployer et tester votre cluster Kubernetes géré dans le cloud IBM gratuitement:
- Inscrivez-vous dans le cloud IBM: https://ibm.biz/rucloud (vous devez confirmer votre adresse e-mail, vous n'avez pas besoin d'ajouter de données de carte de crédit à ce stade)
- Pour utiliser le service IKS, vous pouvez transférer votre compte vers un compte payant (en cliquant sur Mettre à niveau et en entrant les détails de votre carte bancaire - vous recevrez 200 $ sur votre compte). Ou surtout pour les lecteurs du Habr, vous pouvez obtenir un coupon pour passer votre compte en mode d'essai - cela vous permettra de déployer un cluster minimum gratuitement pendant 30 jours. Après cette période, le cluster peut être recréé à nouveau et poursuivre les tests. Vous pouvez demander un coupon sur le lien - https://ibm.biz/cloudcoupon . La confirmation du coupon est effectuée pendant la journée de travail.
- Vous pouvez créer un cluster gratuit (un travailleur 2 vCPU 4 Go de RAM) à partir du catalogue de services - https://cloud.ibm.com/kubernetes/catalog/cluster/create
- La création d'un cluster prendra 5 à 7 minutes, après quoi le cluster IKS sera à votre disposition.
Conclusion
J'espère qu'après avoir lu cet article, le lecteur aura moins de questions sur la gestion des kubernetes et de la gestion du travail en équipe ouverte. Cet article peut également être utilisé comme une instruction d'action sur l'implémentation de vos propres kubernetes. Toutes les pratiques utilisées par IBM sont applicables aux clouds privés et, avec un certain effort, sont mises en œuvre dans n'importe quel centre de données.
Les ressources
IKS mou
https://ibm-container-service.slack.com/
https://www.ibm.com/cloud/blog/announcements/ibm-cloud-activity-tracker-with-logdna-for-ibm-cloud-object-storage
https://www.ibm.com/cloud/blog/announcements/introducing-the-portworx-software-defined-storage-solution
https://cloud.ibm.com/docs/services/Monitoring-with-Sysdig?topic=Sysdig-getting-started