Please enable JavaScript.

Coggle requires JavaScript to display documents.

Vue d'ensemble (Qu'est ce que kubernetes ? (Ce que kubernetes…

- - - - automatiser le déploiement
      - scaler
      - gérer des conteneurs d'applications
  - - - n'impose pas un framework
      - ne restreint pas le type de langage sous-jacent
      - Obéit aux recommandation 12-factors
      - Ne distingue pas les applications des services
      - Supporte différents types de workloads (stateless, stateful, data-processing)
    - - middleware (rabbitMQ)
      - data processing framework (spark)
      - base de données (mysql)
    - - logging
      - monitoring
      - alerting
- - - - Fournissent le pilotage du cluster.
      - Prennent les décisions globales du cluster (scheduling).
      - Détectent et répondent aux évènements du cluster (exemple, créer un nouveau pod quand le champ réplicas est insatisfait)
      - Peuvent être placés sur n'importe quel noeud
      - Pour simplicité, les placer sur la même VM (même noeud) et n'utiliser aucun container ou pod dessus
      - Possibilité de multi-master pour la haute dispo
    - - Expose l'api de kubernetes
      - Front-end du pilote du cluster kubernetes
      - Conçu pour scaler horizontalement (plus d'instances)
    - - Utilisé comme backend de donnée par kubernetes
      - Toutes les données relatives au cluster sont là dedans
      - Il faut TOUJOURs backuper les données d'etcd pour restaurer le cluster k8s
    - - Exécute des controllers, qui sont des threads de fonds s'occupant des routines du cluster
      - Logiquement, ce sont des processus séparés, mais ils compilés en un binaire et exécutés dans un unique process pour réduire la complexité
      - Les controleurs existants:
        
        node controller: gère et réagit aux noeuds down
        
        replication controller: maintient le nombre correct de pods pour chaque objet replication controller sur le système
        
        endpoints controller: peuple les objets "endpoints" (services + pods)
        
        Service Account & Token Controllers: créer les jetons d'accès par défaut aux api et au compte pour les nouveaux namespaces
    - - C'est quoi ?
        
        une stack qui exécute des controllers intéragissant avec un provider cloud sous-jacent
        
        Introduit récemment (feature 1.6)
      - Désactivation
        
        Pour utiliser le kube-controller-manager original, mettre le flag --cloud-provider à external
      - Ca sert à quoi ?
        
        Permettre l'évolution séparée du code propriétaire cloud et du coeur de k8s
        
        Dans les versions précédentes, le code de k8s était dépendant des stacks clouds sous-jacentes
        
        Les adapteurs clouds pour cloud-controller-manager seront désormais proposés par les développeurs de la stack cloud
      - Ce que doivent fournir les cloud-controller-manager des stacks clouds
        
        node controller: vérifier qu'un noeud a bien été supprimé au niveau infra s'il ne répond plus
        
        route controller: configurer le routage vers l'infra cloud
        
        service controller: créer, mettre à jour et supprimer les load-balancers de la stack cloud
        
        volume controller: gérer les volumes en intéraction avec la gestion du stockage dans la stack cloud
    - - Surveille les nouveaux pods générés, et non-encore affectés à un noeud
      - Sélectionne un noeud pour y exécuter les-dits pods
    - - Pods et services implémentant des fonctionnalités du cluster
      - Peuvent être gérés via Deployments et ReplicationControllers
      - Les addons namespaced sont créer dans le namespace kube-system
    - - Seul addon réellement indispensable
      - Sert le DNS pour tous les services k8s
      - Les containers contiennent automatiquement
    - - Gère et debug le cluster
      - Gère et debug les applications sur cluster
    - - Enregistre des time-series dans une base de donnée centrale
      - Propose une UI pour présenter ces données
    - - Sauvegarder les logs des conteneurs en centralisé et proposer une UI de recherche
  - - - C'est quoi ?:
        
        L'agent principal du noeud
      - A quoi sert-il?
        
        Il surveille les pods assignés aux noeuds
        
        Soit à travers l'apiserver
        
        Soit à travers la configuration locale
        
        Monte les volumes des pods
        
        Télécharge les secrets des pods
        
        Démarre les conteneurs du pod via docker
        
        Exécute périodiquement les sondes liveness
        
        Rapporte l'état du pod au reste du système
        
        Rapporte le status du noeud au reste du système
    - - s'exécute sur chaque noeud
      - permet d'exposer des services de l'api en opérant du forwarding de port TCP/UDP
      - les ips et les ports sont déterminées via des variables d'environnement
    - - Version alpha
    - - un daemon qui aide à implémenter du logging cluster
- - - - entité persistante au sein du système k8s
      - utilisé pour représenter l'état du cluster
      - peuvent décrire:
        
        quelles applications conteneurisées tournent (et sur quel noeud)
        
        les ressources disponibles pour cette application
        
        les politiques gouvernant le comportement de ces applications (restart, upgrades, tolérance à la panne)
      - Peut être décrit comme un "enregistrement d'intention" - l'objet est un ordre donné à k8s - "état désiré"
      - manipulés à travers l'api (kubectl utilsie l'api via un cli), ou directement dans l'api d'un code
    - - C'est quoi ?
        
        Deux champs qui définissent un objet k8s
      - Spec
        
        Exprime l'état "désiré"
      - State
        
        Exprime l'état courant
      - Fonctionnement
        
        K8s cherche toujours à harmoniser le champ state et spec d'un objet
        
        la requête api doit recevoir l'objet en format json
        
        kubectl convertit le yaml en json au moment de l'envoi
    - - apiVersion: version de l'apiserver utilisé
      - kind: type de l'objet
      - metadata:
        
        sert à: identifier de façon unique un objet
        
        contient les champs
        
        name
        
        UID
        
        namespace (optionnel)
      - spec: décrit l'état désiré
  - - - Tout objet est identifié de façon non-ambigues par un nom et un UID
      - Pour tout attribut non-unique, utiliser les labels et les annotations
    - - Défini par le client
      - Restrictions
        
        Un seul nom par objet d'un certain type à la fois
        
        longueur max de 253 caractères
        
        alphanumériques, lower, inclus les . et les -
      - Utilisés par les url de l'api (/api/v1/pods/some-name)
    - - Générés par k8s
      - Chaque objet du cluster a un UID unique
      - Leur durée de vie est relative à l'existence même du cluster (etcd ?)
      - unique via leur spatialité et leur temporalité
  - - - Des clusters virtuels alimentés par un unique cluster physique
    - - A gérer de multiples environnements/projets
      - Fournit un scope pour les noms des objets. Les noms se doivent d'être unique dans LEUR namespace.
      - Diviser les ressources du cluster entre els utilisateurs (via les ressource quota)
    - - En dessous d'un dizaine d'utilisateurs, c'est inutile
      - Prochainement, les objets du même namespace auront les même politiques par défaut
      - Attention, usage détourné et faux
        
        Utiliser les namespaces pour gérer les différentes versions d'un soft
        
        Les labels servent à distinguer des ressources dans un même namespace
    - - kubectl get namespaces
      - kubectl --namespace=<insert-namespace-name-here> run nginx --image=nginx
      - kubectl config set-context $(kubectl config current-context) --namespace=<insert-namespace-name-here>
    - - Le FQDN d'un service est de la forme <service-name>.<namespace-name>.svc.cluster.local - si juste <service-name>, le container interrogera dans son propre namespace
      - Permet la même configuration quelque soit le scope (dev, staging et production)
      - Pour traverser les namespaces, utiliser le FQDN
    - - La plupart des objets k8s sont dans des namespaces
      - A part
        
        Les objets namespaces eux-même
        
        Les noeuds (trop bas-niveau)
        
        Les persistentVolumes (trop bas-niveau)
      - Les events peuvent l'être ou non (dépend de l'objet concerné)
  - - - Paires de clef/valeur attachées aux objets k8s (ex: pod)
    - - Attribuer à un objet des infos utiles à l'utilisateur mais pas au système directement
      - Organiser, et sélectionner des sous-ensembles d'objets
      - Peuvent être crée durant la création de l'objet, et modifiés ensuite
      - Permet de créer une structure organisationnelle sans modifier en profondeur les objets k8s
      - Permet le stockage de ces données du côté backend, et non client
    - - un préfixe (optionnel) - séparé par un slash - doit être un sous-domaine DNS
      - un nom (obligatoire) de 63 caractère max, avec [a-z0-9A-Z]-_.[a-z0-9A-Z]
      - sans préfixe, le label est local à l'utilisateur
      - les composants système ajoutant des labels aux objets utilisateurs doivent comporter un prefix
      - les composants de kube-core ont un prefix réservé: kubernetes.io
    - - Généralités
        
        Les labels ne proposent pas intrinsèquement d'assurance d'unicité
        
        Il faut s'attendre à ce que plus objets aient le même label (pour les grouper)
        
        Les sélecteurs sont la primitive de regroupement de k8s
        
        Pour les sélections multiples, utiliser des virgules
        
        Un sélecteur vide sélection,ne tous les objets
        
        Un sélecteur null ne sélectionne aucun objet
        
        les labels de deux controlelrs du même namespace ne doivent pas se chevaucher
      - La contrainte d'égalité
        
        = ou == : égalité
        
        != : inégalité
        
        exemple
        
        environment = production
        
        tier != frontend
      - La contrainte d'appartenance
        
        in : membre de
        
        notin : non membre de
        
        exists : ---
        
        exemple
        
        environment in (production, qa)
        
        tier notin (frontend, backend)
        
        partition
        
        !partition
      - Exemple complet et mélangé
        
        partition in (customerA, customerB),environment!=qa
    - - Dans les requêtes api
        
        exemple: ?labelSelector=environment%3Dproduction,tier%3Dfrontend
      - via kubectl
        
        exemple: kubectl get pods -l 'environment in (production),tier in (frontend)'
      - Dans les services
      - Dans le replicasetController
      - Dans les aures ressources
        
        Job
        
        Deployment
        
        ReplicaSet
        
        DaemonSet
  - - - Des paires de clef/valeurs
      - Attachées aux objets kubernetes
    - - Attache des metadonnées aux objets k8s
      - Ne sert pas à identifier et à sélectionner (rôle des labels)
    - - Informations gérées par un outil de configuration type ansible (distingue ces données de celles gérées par k8s)
      - Versions
        
        Numéro du build
        
        ID de la release
        
        Informations autour de l'image (timestamp)
        
        Git branch
        
        Pull request ID
        
        Hash de l'image
        
        Adresse du registre
      - Pointeurs vers des outils de
        
        Logging
        
        Monitoring
        
        Analytics
      - Metadonnées autour des clients ou des outils
      - Téléphone et mail des personnes responsables
- - - - auto-enregistrement
        
        --register-node=true (comportement par défaut)
        
        un serveur kubelet peut ajouter ou modifier
        
        tous les noeuds, mais ça va changer (chaque kubelet aura des droits sur son noeud uniquement)
      - enregistrement manuel
        
        --register-node=false
        
        Permet de marquer un noeud en "unschedulable", aucun nouveau pod n'y sera attribué, mais les anciens resteront
        
        si le pod est un DaemonsSetController, les modifications au niveau du scheduler ne seront pas prises en compte
    - - adresses
        
        ip interne
        
        hostname
        
        ip externe
      - condition
      - (décrit l'état des noeuds running)
        
        Ready
        
        Prêt à accepter de nouveaux pods
        
        si "False" ou "Unknown
        
        cas 1: le noeud répond quand même
        
        attend la fin d'un timeout (5mn par défaut)
        
        envoi au node-controller l'ordre d'effacement des pods
        
        cas 2: noeud injoignable
        
        si lower than 1.5
        
        force la suppression des noeuds
        
        si higher than 1.5
        
        ne force pas la suppression des noeuds
        
        si le noeud n'arrive pas à connaitre l'état des pods l'administrateur devra les effacer à la main.
        
        OutOfdisk
        
        (pas assez d'espace pour ajouter un pod)
        
        MemoryPressure
        
        La mémoire disponible sur l'hôte est faible
        
        DiskPressure
        
        Le disque disponible sur l'hôte est faible
        
        NetworkUnavailable
      - capacité
        
        décrit les ressources du noeud
        
        nombre max de pods spawnable sur ce noeud
        
        CPU
        
        memory
      - info
        
        contient des informations générales
        
        nom de l'OS
        
        version de kube-proxy
        
        version du kernel
        
        version de kubelet
        
        version de docker
    - - peut être:
        
        une machine physique
        
        une VM
      - machine worker
      - (auparavant nommée "minion")
    - - kube-proxy
      - docker
      - kubelet
    - - kubernetes ne crée pas de noeud
      - il ne fait que les représenter
        
        crée via des servers bare-metal avec gestion de conf
        
        crée via un cloud provider (openstack, aws)
      - noeud valide == tous les services requis tournent + healthcheck (hostname resolvable). Alors les pods peuvent être créer dessus
      - si le noeud est invalide
        
        le noeud est ignoré par le cluster jusqu'à sa validation
        
        ne supprime pas la représentation du noeud dans le cluster, à moins que sa suppression soit effective (manuelle)
      - composant interagissant
        
        node controller
        
        kubelet
        
        kubectl
    - - C'est quoi ?
      - A quoi ça sert ?
        
        contrôle la santé du noeud
        
        responsable du status NodeReady via un heartbeat
        
        Assigne un block CIDR au noeud (optionnel)
        
        maintient la liste des noeuds dans un contexte cloud
        
        si l'un des noeuds est injoignable, il est automatiquement retiré de la liste
      - Gère le cas de l'indisponibilité d'une zone dans un cloud efficacement - https://kubernetes.io/docs/concepts/architecture/nodes/#capacity
    - - gère le CPU et la mémoire
      - le scheduler vérifie la disponibilité pour les noeuds
      - concerne uniquement les containers crées via kubelet
      - préserver des ressources pour des process non-pods
        
        créer des pods placeholder
    - - du cluster au master
        
        noeuds déployés avec certificats, pour communiquer avec l'api
        
        tous les flux terminent sur l'apiserver (pas d'autre composants exposant de services)
      - du master au cluster
        
        de l'api server à kubelet
        
        utilisé pour:
        
        récupérer les logs des pods
        
        attacher un TTY aux pods
        
        fournir la fonctionnalité port-forwarding à kubelet
        
        cette connection aboutit au port HTTPS de kubelet
        
        attention, par défaut, pas de sécurisation
        
        --kubelet-certificate-authority pour sécurisation
        
        possibilité de sécuriser par tunnel ssh l'accès à tous les noeuds
        
        de l'api server aux noeuds, pods et services
        
        connection en http par défault
        
        peuvent être chiffrés, mais ne valideront pas le certificat de l'api server
        
        possibilité de sécuriser par tunnel ssh l'accès à tous les noeuds
  - - - C'est quoi ?
      - un composant qui fait la liaison entre:
        
        Les élements du cluster kubernetes
        
        scheduler
        
        Kubernetes Controller Manager
        
        apiserver
        
        la stack cloud sous-jacente
      - pourquoi ?
        
        découpler les composants, et éviter d'avoir à créer des adapteurs sur tous les composants
      - A quoi ça sert ?
        
        dissocier
        
        le coeur de kubernetes
        
        le code propriétaire des stack clouds
      - surcharge le KCM
      - Kubernetes Controller Manager
        
        le CCM ré-implémente:
        
        Node Controller
        
        obtient l'adresse du noeud et son hostname
        
        instancie le noeud avec un label zone/region
        
        instancie le noeud avec des détails d'instance (taille, type...)
        
        si le noeud ne répond pas, check au niveau du cloud
        
        si noeud supprimé du cloud, le noeud kubernetes est supprimé
        
        Service Controller
        
        Route Controller
        
        Exécute un autre controller:
        
        PersistentVolumeLabelsCcontroller
        
        (attribue la zone et la region en tant que label aux volumes persistants)
        
        Le CCM n'implémente pas les volumes
        
        (complexité trop importante, voir doc)