Cette section répertorie les informations vis-à-vis de la configuration de Kubernetes dans l'environemment WEBCENTRIC.
Kubernetes est une avancé majeur dans l'optimisation des projets informatiques. Il s'agit d'un outil permettant l'orchestration des conteneurs. C'est un terme technique pour dire que c'est une surcouche à Docker permettant de déployer des projets complet, gérer la partie réseau et gérer la charge ainsi que la redondance entre différents serveurs.
Grâce à l'orchestration, il est possible de dimensionner automatiquement le nombre de conteneurs pour chaque projet entre les différents serveurs. Ainsi quand un projet prend une charge plus importante, des nouveaux conteneurs sont démarrés sur l'autre serveur pour absorber la charge. La charge étant mieux répartie, il est possible de mettre plusieurs projets en un minimum de serveurs.
Le client en ligne de commande pour Openshift se trouve à l’adresse suivante : https://github.com/openshift/origin/releases/tag/v3.11.0 Disponible pour Linux / Max / Windows.
Dans le zip, il y a deux programmes :
Le programme oc est une version amélioré de kubectl. Voir les différences entre les deux.
Le mieux sur Linux est de copier les deux programmes oc et kubectl dans le dossier /usr/local/bin.
Pour se connecter, il y a plusieurs moyens :
oc loginkubectloc login depuis un poste de travail. Par contre pour un build automatique, nous recommandons d'utiliser kubectl avec un secret.
oc login https://master1.k8s.wcentric.com:8443
ou
oc login https://master.k8s.japan-expo.com:8443
–token= puis le token (pour la production Equinix).
Puis entrer les informations d’authentification du réseau d’entreprise.
Une fois que vous êtes connecté, choisissez le namespace (ou projet) sur lequel vous souhaitez travailler avec la commande suivante (remplacer MyNameSpace par le namespace à utiliser) :
oc project MyNameSpace
Vous pouvez ensuite effectuer des commandes sur le Kubernetes comme par exemple :
Vous pouvez déployer des applications rapidement pour faire des tests depuis le catalogue d’applications : https://master1.k8s.wcentric.com:8443/console/catalog
Vous pouvez gérer les différents projets depuis la console des projets : https://master1.k8s.wcentric.com:8443/console/projects Cette console permet aussi de consulter les différents éléments des projets (stockage / secrets / configs / routes / droits d’accès / etc…).
La console d'un projet est un moyen simple et efficace pour accéder à tous les objets d'un namespace en particulier.
La console du cluster : https://console.k8s.wcentric.com Cette console est pour l’administration « bas niveau ». Il y a tous les accès aux différents objets de la base de configuration de Kubernetes. Elle est donc moins facile à utiliser que la console des projets.
La console du cluster permet d'avoir une gestion globale de toute l'infrastructure. La plupart des objets de Kubernetes sont accessibles depuis cette console centrale. Certains objets restent néanmoins accessible seulement depuis une les lignes de commandes.
Il faut voir plusieurs éléments dans Kubernetes. D'une part les éléments dit d'infrastructure dont le fonctionnement reste totalement abstrait et indépendant de l'utilisation concrète et les éléments propre à la configuration des différents projets.
Dans Kubernetes, la base est les espaces de noms (les namespaces). Dans le cadre de openshift, ces espaces de nom sont aussi appelés des projets. Chaque espace de nom sont indépendants, ils ne peuvent communiquer entre eux que si des règles spécifiques ont été appliqués.
Un espace de nom permet de regrouper tous les éléments (pod / services / etc.) d'un seul projet. Chaque élément de l'espace de nom a accès aux autres éléments de son espace, mais pas aux éléments des autres espaces. Ils sont utilisés pour correctement isoler plusieurs projets et éviter des failles de sécurité.
Un espace de nom est donc un regroupements d'objets, tous nécessaire à une seule et même application.
Dans ce chapitre, nous n'aborderons pas la configuration et l'utilisation de Kubernetes, mais plutôt comment l'infrastructure fonctionne. La partie invisible qui permet le fonctionnement de tout le cluster.
La base de tout Kubernetes, c'est Docker. Tous les serveurs faisant fonctionner Kubernetes est un simple système avec Docker. Les différentes biques constituant l'infrastructure sont toutes des projets Kubernetes, elles mêmes sous la forme de conteneurs. Chaque serveur constituant l'infrastructure est donc système avec Docker installé.
Par mesure d'efficacité, il est possible de constituer son cluster Kubernetes uniquement avec des systèmes optimisés pour Doker tel que CoreOS ou bien Project Atomic. Mais il est aussi possible de partir d'un OS classique en édition minimal tel que CentOS et y installer Docker.
A noter qu'il n'est pas obligatoire d'utiliser Docker comme engine pour les conteneurs. Il est aussi possible d'utiliser des projets plus stables tel que cri-o.
De base, Kubernetes ne propose pas de système de déploiement automatisé d'OS. Certains projets permettent le déploiement des OS. Chez Webcentric, nous avons mis en place en interne un système sur mesure pour le déploiement des OS et de OpenShift.
Un aspect très important sur Kubernetes, c'est qu'il s'agit d'un orchestrateur seulement. Ce n'est pas une solution tout-en-main. Configurer un cluster Kubernetes « bare metal » peut être relativement long et complexe. Pour faire un rapprochement, Kubernetes est un peu comme le noyeau linux. Il est possible d'installer linux « from scratch », mais l'installation est longue et complexe. Par contre il y a des éditeurs qui proposent des solutions de cluster tout-en-main complète, que se soit sur site ou dans le cloud, exactement comme vous avez Debian ou CentOS comme distribution sur Linux.
Pour Kubernetes, vous pouvez consulter la liste officielle des distributions. Dans le cas de Webcentric, nous nous sommes concentrés sur OKD. C'est la version OpenSource de la distribution OpenShift, proposée par RedHat.
Nous avons vu précédemment que Kubernetes est composé de conteneurs, qui gère d'autres conteneurs. Les différents éléments qui compose le cluster Kubernetes sont donc des conteneurs. Lors de l'installation, il est possible de définir quel serveur va exécuter quel élément qui compose le cluster.
| Rôle | Description |
|---|---|
| Ansible | Réalise le déploiement du cluster. Ce rôle est one-shot et n'est pas nécessaire pour le fonctionnement. |
| Master | Responsable de l'orchestration du cluster. C'est aussi le rôle qui fourni les API de management. |
| Infra | Réalise le routage, c'est le point d'entrée du cluster. |
| Etcd | Base de donnée contenant toute la configuration d'exploitation. |
| Persistent Storage | Stockage persistant des volumes des différents conteneurs. |
| Registry Storage | Stockage persistant du docker registry qui permet de garder en cache les différentes images déployés. |
| Compute | Nœuds où sont exécutés les différents projets. |
En soit, tous les rôles sont des nœuds, avec un sélecteur définissant qu'ils doivent accueillir les pods responsables d'un des éléments d'infrastructure.
La charge de calcul (la partie exécution) de Kubernetes est constitué de Pods. Ces derniers peuvent être créé manuellement, mais sont généralement créé par un contrôleur via des configuration de type Deployment, StatefulSet ou DaemonSet.
Dans le cluster, des adresses sont définies pour tous les services. Ces adresses sont sous la forme : {service}.{nalespace}.svc.cluster.local.
La partie réseau est composée de Services utilisant des endpoints.
Pour le trafic HTTP et HTTPS, il existe Ingress qui permet de rediriger la connexion au bon pod suivant le nom d'hôte et gère la partie SSL. C'est une surcouche aux Services.
Ce namepaces répertorie l'ensemble des applications installé par le système et réseaux comme des services pour les applications. Les applications présentes dans ce namespace sont :
Namespace utilisé pour le serveur Tiller (utilisé par Helm). Il n'y a pas d'application à proprement parlé dans ce namespace.
Namespaces utilisées par Kubernetes (core). Il est notamment utilisé pour tout ce qui est orchestration et API.
Namespaces utilisés pour les différentes couches additionnelles réalisées par RedHat. Ces namespaces comprennent :
Namespace responsable du stockage persistant. Notamment des noeuds GlusterFS pour l'infrastructure de test en local.