Présentations

• Bonjour, je suis:

  • 👨🏾‍🎓 djalal (@enlamp, ENLAMP)

• Cet atelier se déroulera de 9h à 17h.

• La pause déjeuner se fera entre 12h et 13h30.

  (avec 2 pauses café à 10h30 et 15h!)

• N'hésitez pas à m'interrompre pour vos questions, à n'importe quel moment.

• Surtout quand vous verrez des photos de conteneurs en plein écran!

• Vos réactions en direct, questions, demande d'aide
  sur https://tinyurl.com/docker-w-djalal

logistics.md

A brief introduction

• This was initially written by Jérôme Petazzoni to support in-person, instructor-led workshops and tutorials

• Credit is also due to multiple contributors — thank you!

• You can also follow along on your own, at your own pace

• We included as much information as possible in these slides

• We recommend having a mentor to help you ...

• ... Or be comfortable spending some time reading the Kubernetes documentation ...

• ... And looking for answers on StackOverflow and other outlets

k8s/intro.md

À propos de ces diapositives

• Tout le contenu est disponible dans un dépôt public Github:

  https://github.com/jpetazzo/container.training

• Vous pouvez obtenir une version à jour de ces diapos ici:

  https://container.training/ (anglais) ou https://docker.djal.al/ (français)

Chapitre 1

• Pre-requis

• Notre application de démo

• Concepts Kubernetes

• Déclaratif vs Impératif

• Modèle réseau de Kubernetes

(auto-generated TOC)

Chapitre 2

• Premier contact avec kubectl

• Installer Kubernetes

• Lancer nos premiers conteneurs sur Kubernetes

• Exposer des conteneurs

(auto-generated TOC)

Chapitre 3

• Shipping images with a registry

• Running our application on Kubernetes

• Accessing the API with kubectl proxy

• Controlling the cluster remotely

• Accessing internal services

• The Kubernetes dashboard

• Security implications of kubectl apply

• Scaling our demo app

(auto-generated TOC)

Chapitre 4

• Daemon sets

• Labels and selectors

• Rolling updates

• Namespaces

• Kustomize

(auto-generated TOC)

Chapitre 5

• Healthchecks

• Accessing logs from the CLI

• Centralized logging

• Authentication and authorization

• The CSR API

• Pod Security Policies

(auto-generated TOC)

Chapitre 6

• Exposing HTTP services with Ingress resources

• Collecting metrics with Prometheus

(auto-generated TOC)

Chapitre 7

• Volumes

• Managing configuration

(auto-generated TOC)

Chapitre 8

• Stateful sets

• Running a Consul cluster

• Local Persistent Volumes

• Static pods

(auto-generated TOC)

Chapitre 9

• Next steps

• Links and resources

(auto-generated TOC)

shared/toc.md

Pre-requis

• Être à l'aise avec la ligne de commande UNIX

  • se déplacer à travers les dossiers

  • modifier des fichiers

  • un petit peu de bash-fu (variables d'environnement, boucles)

• Un peu de savoir-faire sur Docker

  • docker run, docker ps, docker build

  • idéalement, vous savez comment écrire un Dockerfile et le générer.
    (même si c'est une ligne FROM et une paire de commandes RUN)

• C'est totalement autorisé de ne pas être un expert Docker!

shared/prereqs.md

Sections pratiques

• Cet atelier est entièrement pratique

• Nous allons construire, livrer et exécuter des conteneurs!

• Vous être invité(e) à reproduire toutes les démos

• Les sections "pratique" sont clairement identifiées, via le rectangle gris ci-dessous

shared/prereqs.md

Doing or re-doing the workshop on your own?

• Use something like Play-With-Docker or Play-With-Kubernetes

  Zero setup effort; but environment are short-lived and might have limited resources

• Create your own cluster (local or cloud VMs)

  Small setup effort; small cost; flexible environments

• Create a bunch of clusters for you and your friends (instructions)

  Bigger setup effort; ideal for group training

shared/connecting.md

On travaillera (surtout) avec node1

Ces remarques s'appliquent uniquement en cas de serveurs multiples, bien sûr.

• Sauf contre-indication expresse, toutes les commandes sont lancées depuis la première VM, node1

• Tout code sera récupéré sur node1 uniquement.

• En administration classique, nous n'avons pas besoin d'accéder aux autres serveurs.

• Si nous devions diagnostiquer une panne, on utiliserait tout ou partie de:

  • SSH (pour accéder aux logs de système, statut du daemon, etc.)

  • l'API Docker (pour vérifier les conteneurs lancés, et l'état du moteur de conteneurs)

shared/connecting.md

Terminaux

Once in a while, the instructions will say:
"Open a new terminal."

There are multiple ways to do this:

• create a new window or tab on your machine, and SSH into the VM;

• use screen or tmux on the VM and open a new window from there.

You are welcome to use the method that you feel the most comfortable with.

shared/connecting.md

Tmux cheatsheet

Tmux is a terminal multiplexer like screen.

You don't have to use it or even know about it to follow along.
But some of us like to use it to switch between terminals.
It has been preinstalled on your workshop nodes.

• Ctrl-b c → creates a new window
• Ctrl-b n → go to next window
• Ctrl-b p → go to previous window
• Ctrl-b " → split window top/bottom
• Ctrl-b % → split window left/right
• Ctrl-b Alt-1 → rearrange windows in columns
• Ctrl-b Alt-2 → rearrange windows in rows
• Ctrl-b arrows → navigate to other windows
• Ctrl-b d → detach session
• tmux attach → reattach to session

shared/connecting.md

Versions installées

• Kubernetes 1.14.3
• Docker Engine 18.09.6
• Docker Compose 1.21.1

k8s/versions-k8s.md

Notre application de démo

• Nous allons cloner le dépôt Github sur notre node1

• Le dépôt contient aussi les scripts et outils à utiliser à travers la formation.

(Vous pouvez aussi forker le dépôt sur Github et cloner votre version si vous préférez.)

shared/sampleapp.md

Télécharger et lancer l'application

Démarrons-la avant de s'y plonger, puisque le téléchargement peut prendre un peu de temps...

Compose indique à Docker de construire toutes les images de conteneurs (en téléchargeant les images de base correspondantes), puis de démarrer tous les conteneurs et d'afficher les logs agrégés.

shared/sampleapp.md

Qu'est-ce que cette application?

DockerCoins à l'âge des microservices

• DockerCoins est composée de 5 services:

  • rng = un service web générant des octets au hasard

  • hasher = un service web calculant un hachage basé sur les données POST-ées

  • worker = un processus en arrière-plan utilisant rng et hasher

  • webui = une interface web pour le suivi du travail

  • redis = base de données (garde un décompte, mis à jour par worker)

• Ces 5 services sont visibles dans le fichier Compose de l'application, docker-compose.yml

shared/sampleapp.md

Comment fonctionne DockerCoins

• worker invoque le service web rng pour générer quelques octets aléatoires

• worker invoque le service web hasher pour générer un hachage de ces octets

• worker reboucle de manière infinie sur ces 2 tâches

• chaque seconde, worker écrit dans redis pour indiquer combien de boucles ont été réalisées

• webui interroge redis, pour calculer et exposer la "vitesse de hachage" dans notre navigateur

(Voir le diagramme en diapo suivante!)

shared/sampleapp.md

Service discovery au pays des conteneurs

• Comment chaque service trouve l'adresse des autres?

Exemple dans worker/worker.py

redis = Redis("redis")
def get_random_bytes():
    r = requests.get("http://rng/32")
    return r.content
def hash_bytes(data):
    r = requests.post("http://hasher/",
                      data=data,
                      headers={"Content-Type": "application/octet-stream"})

(Code source complet disponible ici)

shared/sampleapp.md

Montrez-moi le code!

• Vous pouvez ouvrir le dépôt Github avec tous les contenus de cet atelier:
  https://github.com/jpetazzo/container.training

• Cette application est dans le sous-dossier dockercoins

• Le fichier Compose (docker-compose.yml) liste les 5 services

• redis utilise une image officielle issue du Docker Hub

• hasher, rng, worker, webui sont générés depuis un Dockerfile

• Chaque Dockerfile de service et son code source est stocké dans son propre dossier

  (hasher est dans le dossier hasher, rng est dans le dossier rng, etc.)

shared/sampleapp.md

Notre application à l'oeuvre

• A votre gauche, la bande "arc-en-ciel" montrant les noms de conteneurs

• A votre droite, nous voyons la sortie standard de nos conteneurs

• On peut voir le service worker exécutant des requêtes vers rng et hasher

• Pour rng et hasher, on peut lire leur logs d'accès HTTP

shared/sampleapp.md

Se connecter à l'interface web

• "Les logs, c'est excitant et drôle" (Citation de personne, jamais, vraiment)

• Le conteneur webui expose un écran de contrôle web; allons-y voir.

Un diagramme devrait s'afficher, et après quelques secondes, une courbe en bleu va apparaître.

shared/sampleapp.md

Arrêter notre application

• Si nous stoppons Compose (avec ^C), il demandera poliment au Docker Engine d'arrêter l'appli

• Le Docker Engine va envoyer un signal TERM aux conteneurs

• Si les conteneurs ne quittent pas assez vite, l'Engine envoie le signal KILL

Nettoyage

• Avant de continuer, supprimons tous ces conteneurs.

shared/composedown.md

Concepts Kubernetes

• Kubernetes est un système de gestion de conteneurs

• Il lance et gère des applications conteneurisées sur un cluster

Tâches de base qu'on peut demander à Kubernetes

D'autres choses que Kubernetes peut faire pour nous

• Montée en charge basique

• Déploiement Blue/Green, déploiement canary

• Services de longue durée, mais aussi des tâches par lots (batch)

• Surcharger notre cluster et évincer les tâches de basse priorité

• Lancer des services à données persistentes (bases de données, etc.)

• Contrôle d'accès assez fin, pour définir quelle action est autorisée pour qui sur quelle ressources.

• Intégrer les services tiers (catalogue de services)

• Automatiser des tâches complexes (opérateurs)

k8s/concepts-k8s.md

Architecture Kubernetes

k8s/concepts-k8s.md

Architecture Kubernetes

• Ha ha ha ha

• OK, je voulais juste vous faire peur, c'est plus simple que ça ❤️

k8s/concepts-k8s.md

Crédits

• Le premier schéma est un cluster Kubernetes avec du stockage sur l'iSCSI multi-path

  (Grâce à Yongbok Kim)

• Le second est une représentation simplifiée d'un cluster Kubernetes

  (Grâce à Imesh Gunaratne)

k8s/concepts-k8s.md

Architecture de Kubernetes: les nodes

• Les nodes qui font tourner nos conteneurs ont aussi une collection de services:

  • un moteur de conteneurs (typiquement Docker)

  • kubelet (l'agent de node)

  • kube-proxy (un composant réseau nécessaire mais pas suffisant)

• Les nodes étaient précédemment appelées des "minions"

  (On peut encore rencontrer ce terme dans d'anciens articles ou documentation)

k8s/concepts-k8s.md

Architecture Kubernetes: le plan de contrôle

• La logique de Kubernetes (ses "méninges") est une collection de services:

  • Le serveur API (notre point d'entrée pour toute chose!)

  • des services principaux comme l'ordonnanceur et le contrôleur

  • etcd (une base clé-valeur hautement disponible; la "base de données" de Kubernetes)

• Ensemble, ces services forment le plan de contrôle de notre cluster

• Le plan de contrôle est aussi appelé le "master"

k8s/concepts-k8s.md

Interagir avec Kubernetes

• Le dialogue avec Kubernetes s'effectue via une API RESTful, la plupart du temps.

• L'API Kubernetes définit un tas d'objets appelés resources

• Ces ressources sont organisées par type, ou Kind (dans l'API)

• Elle permet de déclarer, lire, modifier et supprimer les resources

• Quelques types de ressources communs:

  • node (une machine - physique ou virtuelle - de notre cluster)
  • pod (groupe de conteneurs lancés ensemble sur une node)
  • service (point d'entrée stable du réseau pour se connecter à un ou plusieurs conteneurs)

  Et bien plus!

• On peut afficher la liste complète avec kubectl api-resources

k8s/concepts-k8s.md

Crédits

• Le premier diagramme est une grâcieuseté de Lucas Käldström, dans cette présentation

  • c'est l'un des meilleurs diagrammes d'architecture Kubernetes disponibles!

• Le second diagramme est une grâcieuseté de Weave Works

  • un pod peut avoir plusieurs conteneurs qui travaillent ensemble

  • les adresses IP sont associées aux pods, pas aux conteneurs eux-mêmes

Les deux diagrammes sont utilisés avec la permission de leurs auteurs.

k8s/concepts-k8s.md

Déclaratif vs Impératif

• Notre orchestrateur de conteneurs insiste fortement sur sa nature déclarative

• Déclaratif:

  Je voudrais une tasse de thé

• Impératif:

  Faire bouillir de l'eau. Verser dans la théière. Ajouter les feuilles de thé. Infuser un moment. Servir dans une tasse.

Déclaratif vs Impératif

• Ce que le mode déclaratif devrait vraiment être:

  Je voudrais une tasse de thé, obtenue en versant une infusion¹ de feuilles de thé dans une tasse.

Déclaratif vs Impératif

• Système impératifs:

  • plus simple

  • si une tache est interrompue, on doit la redémarrer de zéro

• Système déclaratifs:

  • si une tache est interrompue (ou si on arrive en plein milieu de la fête), on peut déduire ce qu'il manque, et on complète juste par ce qui est nécessaire.

  • on doit être en mesure d'observer le système

  • ... et de calculer un "diff" entre ce qui tourne en ce moment et ce que nous souhaitons

shared/declarative.md

Déclaratif vs Impératif dans Kubernetes

• Pratiquement tout ce que nous lançons sur Kubernetes est déclaré dans une spec

• Tout ce qu'on peut faire est écrire un spec et la pousser au serveur API

  (en déclarant des ressources comme Pod ou Deployment)

• Le serveur API va valider cette spec (la rejeter si elle est invalide)

• Puis la stocker dans etcd

• Un controller va "repérer" cette spécification et réagir en conséquence

k8s/declarative.md

Réconciliation d'état

• Gardez un oeil sur les champs spec dans les fichiers YAML plus tard!

• La spec décrit comment on voudrait que ce truc tourne

• Kubernetes va réconcilier l'état courant avec la spec
  (techniquement, c'est possible via un tas de controllers)

• Quand on veut changer une ressources, on modifie la spec

• Kubernetes va alors faire converger cette ressource

k8s/declarative.md

Modèle réseau de Kubernetes

• En un mot comme en cent:

  Notre cluster (nodes et pods) est un grand réseau IP tout plat.

Modèle réseau de Kubernetes: le bon

• Tout peut se connecter à tout

• Pas de traduction d'adresse

• Pas de traduction de port

• Pas de nouveau protocole

• L'implémentation réseau peut décider comment allouer les adresses

• Les adresses IP n'ont pas à être "portables" d'une node à une autre.

  (On peut avoir par ex. un sous-réseau par node et utiliser une topologie simple)

• La spécification est assez simple pour permettre différentes implémentations variées

k8s/kubenet.md

Modèle réseau de Kubernetes: le moins bon

• Tout peut se connecter à tout

  • si on cherche de la sécurité, on devra rajouter des règles réseau

  • l'implémentation réseau que vous choisirez devra offrir cette fonction

• Il y a littéralement des dizaines d'implémentations dans le monde

  (Pas moins de 15 sont mentionnées dans la documentation Kubernetes)

• Les pods ont une connectivité de niveau 3 (IP), et les services de niveau 4 (TCP ou UDP)

  (Les services sont associés à un seul port TCP ou UDP; pas de groupe de ports ou de paquets IP arbitraires)

• kube-proxy est sur le chemin de données quand il se connecte à un pod ou conteneur,
  et ce n'est pas particulièrement rapide (il s'appuie sur du proxy utilisateur ou iptables)

k8s/kubenet.md

Modèle réseau de Kubernetes: en pratique

• Les nodes que nous avons à notre disposition utilisent Weave

• On ne recommande pas Weave plus que ça, c'est juste que "Ca Marche Pour Nous"

• Pas d'inquiétude à propos des réserves sur la performance kube-proxy

• Sauf si vous:

  • saturez régulièrement des interfaces réseaux 10Gbps
  • comptez les flux de paquets par millions à la seconde
  • lancez des plate-formes VOIP ou de jeu de haut trafic
  • faites des trucs bizarres qui lancent des millions de connexions simultanées
    (auquel cas vous êtes déjà familier avec l'optimisation du noyau)

• Si nécessaire, des alternatives à kube-proxy existent, comme: kube-router

k8s/kubenet.md

Premier contact avec kubectl

• kubectl est (presque) le seul outil dont nous aurons besoin pour parler à Kubernetes

• C'est un outil en ligne de commande très riche, autour de l'API Kubernetes

  (Tout ce qu'on peut faire avec kubectl, est directement exécutable via l'API)

• Sur nos machines, on trouvera un fichier ~/.kube/config avec:

  • l'adresse de l'API Kubernetes

  • le chemin vers nos certificats TLS d'identification

• On peut aussi utiliser l'option --kubeconfig pour forcer un fichier de config

• Ou passer directement --server, --user, etc.

• kubectl se prononce "Cube Cé Té Elle", "Cube coeuteule", "Cube coeudeule"

k8s/kubectlget.md

kubectl get

• Jetons un oeil aux ressources Node avec kubectl get!

k8s/kubectlget.md

Obtenir un affichage version "machine"

• kubectl get peut afficher du JSON, YAML ou un format personnalisé

k8s/kubectlget.md

User et abuser de kubectl et jq

• C'est super facile d'afficher ses propres rapports

k8s/kubectlget.md

Nommage de types

• Les ressources les plus communes ont jusqu'à 3 formes de noms:

  • singulier (par ex. node, service, deployment)

  • pluriel (par ex. nodes, services, deployments)

  • court (par ex. no, svc, deploy)

• Certaines ressources n'ont pas de nom court

• Endpoints n'ont qu'une forme au pluriel

  (parce que même une seule ressource Endpoints est en fait une liste d'endpoints)

k8s/kubectlget.md

Détailler l'affichage

• On peut taper kubectl get -o yaml pour un détail complet d'une ressource

• Toutefois, le format YAML peut être à la fois trop verbeux et incomplet

• Par exemple, kubectl get node node1 -o yaml est:

  • trop verbeux (par ex. la liste des images disponibles sur cette node)

  • incomplet (car on ne voit pas les pods qui y tournent)

  • difficile à lire pour un administrateur humain

• Pour une vue complète, on peut utiliser kubectl describe en alternative.

k8s/kubectlget.md

kubectl describe

• kubectl describe requiert un type de ressource et (en option) un nom de ressource

• Il est possible de fournir un préfixe de nom de ressource

  (tous les objets contenant ce nom seront affichés)

• kubectl describe va récupérer quelques infos de plus sur une ressource

(On devrait voir un tas de pods du plan de contrôle)

k8s/kubectlget.md

Services

• Un service est un point d'entrée stable pour se connecter à "quelque chose"

  (Dans la proposition initiale, on appelait ça un "portail")

services ClusterIP

• Un service ClusterIP est interne, disponible uniquement depuis le cluster

• C'est utile pour faire l'introspection depuis l'intérieur de conteneurs.

NB :sur Docker for Desktop, l'API n'est accessible que sur https://localhost:6443/

Lister les conteneurs qui tournent

• Les conteneurs existent à travers des pods.

• Un pod est un groupe de conteneurs:

  • qui tournent ensemble (sur le même noeud)

  • qui partagent des ressources (RAM, CPU; mais aussi réseau et volumes)

Namespaces

• Les espaces de nommage (namespaces) nous permettent de cloisonner des ressources.

Accéder aux namespaces

• Par défaut, kubectl utilise le namespace... default

• On peut montrer toutes les ressources avec --all-namespaces

.exercise[

• Lister les pods à travers tous les namespaces:

  kubectl get pods --all-namespaces

• Depuis Kubernetes 1.14, on peut aussi taper -A pour faire plus court:

  kubectl get pods -A

Et voici nos pods système!

k8s/kubectlget.md

A quoi servent ces pods du plan de contrôle?

• etcd est notre serveur etcd

• kube-apiserver est le serveur API

• kube-controller-manager et kube-scheduler sont d'autres composants maître

• coredns fournit une découverte de services basé sur le DNS (il remplace kube-dns depuis 1.11)

• kube-proxy tourne sur chaque node et gère le mapping de ports etc.

• weave est le composant qui gère les réseaux superposés sur chaque noeud

• la colonne READY indique le nombre de conteneurs dans chaque pod

• les pods avec un nom qui finit en -node1 sont les composants maître
  ils sont spécifiquement "scotchés" au noeud maître.

k8s/kubectlget.md

Viser un autre namespace

• On peut aussi examiner un autre namespace (que default)

k8s/kubectlget.md

Namespaces selon les commandes kubectl

• On peut combiner -n/--namespace avec presque toute commande

• Exemple:

  • kubectl create --namespace=X pour créer quelque chose dans le namespace X

• On peut utiliser -A/--all-namespaces avec la plupart des commandes qui manipulent plein d'objets à la fois

• Exemples:

  • kubectl delete supprime des ressources à travers plusieurs namespaces

  • kubectl label ajoute/supprime des labels à travers plusieurs namespaces

k8s/kubectlget.md

Installer Kubernetes

• Comment avons-nous installé les clusters Kubernetes à qui on parle?

Inconvénients kubeadm

• N'installe ni Docker ni autre moteur de conteneurs

• N'installe pas de réseau overlay

• N'installe pas de mode multi-maître (pas de haute disponibilité)

Autres options de déploiement

• Si vous êtes sur Azure: AKS

• Si vous êtes sur Google Cloud: GKE

• Si vous êtes sur AWS: EKS, eksctl

• Agnostique au cloud (AWS/DO/GCE (beta)/vSphere(alpha)): kops

• Sur votre machine locale: minikube, kubespawn, Docker Desktop

• Si vous avez un déploiement spécifique: kubicorn

  Sans doute à ce jour l'outil le plus proche d'une solution multi-cloud/hybride, mais encore en développement.

k8s/setup-k8s.md

Encore plus d'options de déploiement

• Si vous aimez Ansible: kubespray

• Si vous aimez Terraform: typhoon

• Si vous aimez Terraform et Puppet: tarmak

• Vous pouvez aussi apprendre à installer chaque composant manuellement, avec l'excellent tutoriel Kubernetes The Hard Way

  Kubernetes The Hard Way est optimisé pour l'apprentissage, ce qui implique de prendre les détours obligatoires à la compréhension de chaque étape nécessaire pour la construction d'un cluster Kubernetes.

• Il y a aussi nombre d'options commerciales disponibles!

• Pour une liste plus complète, veuillez consulter la documentation Kubernetes:
  on y trouve un super guide pour choisir la bonne piste

k8s/setup-k8s.md

Lancer nos premiers conteneurs sur Kubernetes

• Commençons par le commencement: on ne lance pas "un" conteneur

Démarrer un simple pod avec kubectl run

• On doit spécifier au moins un nom et l'image qu'on veut utiliser.

Dans les coulisses de kubectl run

• Jetons un oeil aux ressources créées par kubectl run

Que représentent ces différentes choses?

• Un deployment est une structure de haut niveau

  • permet la montée en charge, les mises à jour, les retour-arrière

  • plusieurs déploiements peuvent être cumulés pour implémenter un canary deployment

  • délègue la gestion des pods aux replica sets

• Un replica set est une structure de bas niveau

  • s'assure qu'un nombre de pods identiques est lancé

  • permet la montée en chage

  • est rarement utilisé directement

• Un replication controlller est l'ancêtre (déprécié) du replica set

k8s/kubectlrun.md

Notre déploiement pingpong

• kubectl run déclare un deployment, deployment.apps/pingpong

NAME                       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/pingpong   1         1         1            1           10m

• Ce déploiement a généré un replica set, replicaset.apps/pingpong-xxxxxxxxxx

NAME                                  DESIRED   CURRENT   READY     AGE
replicaset.apps/pingpong-7c8bbcd9bc   1         1         1         10m

• Ce replica set a créé un pod, pod/pingpong-xxxxxxxxxx-yyyyy

NAME                            READY     STATUS    RESTARTS   AGE
pod/pingpong-7c8bbcd9bc-6c9qz   1/1       Running   0          10m

• Nous verrons plus tard comment ces gars vivent ensemble pour:

  • la montée en charge, la haute disponibilité, les mises à jour en continu

k8s/kubectlrun.md

Afficher la sortie du conteneur

• Essayons la commande kubectl logs

• On lui passera soit un nom de pod ou un type/name

  (Par ex., si on spécifie un déploiement ou un replica set, il nous sortira le premier pod qu'il contient)

• Sauf instruction expresse, la commande n'affichera que les logs du premier conteneur du pod

  (Heureusement qu'il n'y en a qu'un chez nous!)

k8s/kubectlrun.md

Suivre les logs en temps réel

• Tout comme docker logs, kubectl logs supporte des options bien pratiques:

  • -f/--follow pour continuer à afficher les logs en temps réel (à la tail -f)

  • --tail pour indiquer combien de lignes on veut afficher (depuis la fin)

  • --since pour afficher les logs après un certain timestamp

k8s/kubectlrun.md

Escalader notre application

• On peut ajouter plusieurs exemplaires de notre conteneur (notre pod, pour être plus précis), avec la commande kubectl scale

Note: et si on avait essayé d'escalader replicaset.apps/pingpong-xxxxxxxxxx?

On pourrait! Mais le deployment le remarquerait tout de suite, et le baisserait au niveau initial.

k8s/kubectlrun.md

Résilience

• Le déploiement pingpong affiche son replica set

• Le replica set s'assure que le bon nombre de pods sont lancés

• Que se passe-t-il en cas de disparition inattendue de pods?

k8s/kubectlrun.md

Et si on voulait que ça se passe différemment?

• Et si on voulait lancer un conteneur "one-shot" qui ne va pas se relancer?

• On pourrait utiliser kubectl run --restart=OnFailure or kubectl run --restart=Never

• Ces commandes iraient déclarer des jobs ou pods au lieu de deployments.

• Sous le capot, kubectl run invoque des "generators" pour déclarer les descriptions de ressources.

• On pourrait aussi écrire ces descriptions de ressources nous-mêmes (typiquement en YAML),
  et les créer sur le cluster avec kubectl apply -f (comme on verra plus loin)

• Avec kubectl run --schedule=..., on peut aussi lancer des cronjobs

k8s/kubectlrun.md

Bon, et cet avertissement de déprécation?

• Comme nous avons vu dans les diapos précédentes, kubectl run peut faire bien des choses.

• Le type exact des ressources créées n'est pas flagrant.

• Pour rendre les choses plus explicites, on préfère passer par kubectl create:

  • kubectl create deployment pour créer un déploiement

  • kubectl create job pour créer un job

  • kubectl create cronjob pour lancer un job à intervalle régulier
    (depuis Kubernetes 1.14)

• Finalement, kubectl run ne sera utilisé que pour démarrer des pods à usage unique

  (voir https://github.com/kubernetes/kubernetes/pull/68132)

k8s/kubectlrun.md

Divers moyens de créer des ressources

• kubectl run

  • facile pour débuter
  • versatile

• kubectl create <ressource>

  • explicite, mais lui manque quelques fonctions
  • ne peut déclarer de CronJob avant Kubernetes 1.14
  • ne peut pas transmettre des arguments en ligne de commande aux déploiements

• kubectl create -f foo.yaml ou kubectl apply -f foo.yaml

  • 100% des fonctions disponibles
  • exige d'écrire du YAML

k8s/kubectlrun.md

Afficher les logs de multiple pods

• Quand on spécifie un nom de déploiement, les logs d'un seul pod sont affichés

• On peut afficher les logs de plusieurs pods en ajoutant un selector

• Un sélecteur est une expression logique basée sur des labels

• Pour faciliter les choses, quand on lance kubectl run monpetitnom, les objets associés ont un label run=monpetitnom

k8s/kubectlrun.md

Suivre les logs de plusieurs pods

• Est-ce qu'on peut suivre les logs de tous nos pods pingpong?

Note: combiner les options -l et -f est possible depuis Kubernetes 1.14!

Essayons de comprendre pourquoi ...

k8s/kubectlrun.md

Limitations de kubectl logs

• On ne voit pas quel pod envoie quelle ligne

• Si les pods sont redémarrés / remplacés, le flux de log se fige.

• Si de nouveaux pods arrivent, on ne verra pas leurs logs.

• Pour suivre les logs de plusieur pods, il nous faut écrire un sélecteur

• Certains outils externes corrigent ces limitations:

  (par ex.: Stern)

k8s/kubectlrun.md

Est-ce qu'on n'est pas en train de submerger 1.1.1.1?

• Si on y réfléchit, c'est une bonne question!

• Pourtant, pas d'inquiétude:

  Le groupe de recherche APNIC a géré les adresses 1.1.1.1 et 1.0.0.1. Alors qu'elles étaient valides, tellement de gens les ont introduit dans divers systèmes, qu'ils étaient continuellement submergés par un flot de trafic polluant. L'APNIC voulait étudier cette pollution mais à chaque fois qu'ils ont essayé d'annoncer les IPs, le flot de trafic a submergé tout réseau conventionnel.

  (Source: https://blog.cloudflare.com/announcing-1111/)

• Il est tout à fait improbable que nos pings réunis puissent produire ne serait-ce qu'un modeste truc dans le NOC chez Cloudflare!

k8s/kubectlrun.md

19,000 mots

On dit "qu'une image vaut mille mots".

Les 19 diapos suivantes montrent ce qu'il se passe quand on lance:

kubectl run web --image=nginx --replicas=3

k8s/deploymentslideshow.md

Exposer des conteneurs

• kubectl expose crée un service pour des pods existant

• Un service est une adresse stable pour un (ou plusieurs) pods

• Si on veut se connecter à nos pods, on doit déclarer un nouveau service

• Une fois que le service est créé, CoreDNS va nous permettre d'y accéder par son nom

  (i.e après avoir créé le service hello, le nom hello va pointer quelque part)

• Il y a différents types de services, détaillé dans les diapos suivantes:

  ClusterIP, NodePort, LoadBalancer, ExternalName

k8s/kubectlexpose.md

Types de service de base

• ClusterIP (type par défaut)

  • une adresse IP virtuelle est allouée au service (dans un sous-réseau privé interne)
  • cette adresse IP est accessible uniquement de l'intérieur du cluster (noeuds et pods)
  • notre code peut se connecter au service par le numéro de port d'origine.

• NodePort

  • un port est alloué pour le service (par défaut, entre 30000 et 32768)
  • ce port est exposé sur toutes les nodes et quiconque peut s'y connecter
  • notre code doit être modifié pour pouvoir s'y connecter

Ces types de service sont toujours disponibles.

Sous le capot: kube-proxy passe par un proxy utilisateur et un tas de règles iptables.

k8s/kubectlexpose.md

Autres types de service

• LoadBalancer

  • un répartiteur de charge externe est alloué pour le service
  • le répartiteur de charge est configuré en accord
    (par ex.: un service NodePort est créé, et le répartiteur y envoit le traffic vers son port)
  • disponible seulement quand l'infrastructure sous-jacente fournit une sorte de "load balancer as a service"
    (e.g. AWS, Azure, GCE, OpenStack...)

• ExternalName

  • l'entrée DNS gérée par CoreDNS est juste un enregistrement CNAME
  • ni port, ni adresse IP, ni rien d'autre n'est alloué

k8s/kubectlexpose.md

Lancer des conteneurs avec ouverture de port

• Puisque ping n'a nulle part où se connecter, nous allons lancer quelque chose d'autre

• On pourrait utiliser l'image officielle nginx, mais...

  ... comment distinguer un backend d'un autre!

• On va plutôt passer par jpetazzo/httpenv, un petit serveur HTTP écrit en Go

• jpetazzo/httpenv écoute sur le port 8888

• Il renvoie ses variables d'environnement au format JSON

• Les variables d'environnement vont inclure HOSTNAME, qui aura pour valeur le nom du pod

  (et de ce fait, elle aura une valeur différente pour chaque backend)

k8s/kubectlexpose.md

Créer un déploiement pour notre serveur HTTP

• On pourrait lancer kubectl run httpenv --image=jpetazzo/httpenv ...

• Mais puisque kubectl run est bientôt obsolète, voyons voir comment utiliser kubectl create à sa place.

k8s/kubectlexpose.md

Exposer notre déploiement

• Nous allons déclarer un service ClusterIP par défaut

k8s/kubectlexpose.md

Services: constructions de 4e couche

• On peut assigner des adresses IP aux services, mais elles restent dans la couche 4

  (i.e un service n'est pas une adresse IP; c'est une IP+ protocole + port)

• La raison en est l'implémentation actuelle de kube-proxy

  (qui se base sur des mécanismes qui ne supportent pas la couche n°3)

• Il en résulte que: vous devez indiquer le numéro de port de votre service

• Lancer des services avec un (ou plusieurs) ports au hasard demandent des bidouilles

  (comme passer le mode réseau au niveau hôte)

k8s/kubectlexpose.md

Tester notre service

• Nous allons maintenant envoyer quelques requêtes HTTP à nos pods

Exposer des services au monde extérieur

• Le type par défaut (ClusterIP) ne fonctionne que pour le trafic interne

• Si nous voulons accepter du trafic depuis l'extene, on devra utiliser soit:

  • NodePort (exposer un service sur un port TCP entre 30000 et 32768)

  • LoadBalancer (si notre fournisseur de cloud est compatible)

  • ExternalIP (passer par l'adresse IP externe d'une node)

  • Ingress (mécanisme spécial pour les services HTTP)

Nous détaillerons l'usage des NodePorts et Ingresses plus loin.

k8s/kubectlexpose.md

Shipping images with a registry

• Initially, our app was running on a single node

• We could build and run in the same place

• Therefore, we did not need to ship anything

• Now that we want to run on a cluster, things are different

• The easiest way to ship container images is to use a registry

k8s/shippingimages.md

How Docker registries work (a reminder)

• What happens when we execute docker run alpine ?

• If the Engine needs to pull the alpine image, it expands it into library/alpine

• library/alpine is expanded into index.docker.io/library/alpine

• The Engine communicates with index.docker.io to retrieve library/alpine:latest

• To use something else than index.docker.io, we specify it in the image name

• Examples:

  docker pull gcr.io/google-containers/alpine-with-bash:1.0
  docker build -t registry.mycompany.io:5000/myimage:awesome .
  docker push registry.mycompany.io:5000/myimage:awesome

k8s/shippingimages.md

Running DockerCoins on Kubernetes

• Create one deployment for each component

  (hasher, redis, rng, webui, worker)

• Expose deployments that need to accept connections

  (hasher, redis, rng, webui)

• For redis, we can use the official redis image

• For the 4 others, we need to build images and push them to some registry

k8s/shippingimages.md

Building and shipping images

• There are many options!

• Manually:

  • build locally (with docker build or otherwise)

  • push to the registry

• Automatically:

  • build and test locally

  • when ready, commit and push a code repository

  • the code repository notifies an automated build system

  • that system gets the code, builds it, pushes the image to the registry

k8s/shippingimages.md

Which registry do we want to use?

• There are SAAS products like Docker Hub, Quay ...

• Each major cloud provider has an option as well

  (ACR on Azure, ECR on AWS, GCR on Google Cloud...)

• There are also commercial products to run our own registry

  (Docker EE, Quay...)

• And open source options, too!

• When picking a registry, pay attention to its build system

  (when it has one)

k8s/shippingimages.md

Using images from the Docker Hub

• For everyone's convenience, we took care of building DockerCoins images

• We pushed these images to the DockerHub, under the dockercoins user

• These images are tagged with a version number, v0.1

• The full image names are therefore:

  • dockercoins/hasher:v0.1

  • dockercoins/rng:v0.1

  • dockercoins/webui:v0.1

  • dockercoins/worker:v0.1

k8s/buildshiprun-dockerhub.md

Setting $REGISTRY and $TAG

• In the upcoming exercises and labs, we use a couple of environment variables:

  • $REGISTRY as a prefix to all image names

  • $TAG as the image version tag

• For example, the worker image is $REGISTRY/worker:$TAG

• If you copy-paste the commands in these exercises:

  make sure that you set $REGISTRY and $TAG first!

• For example:

  export REGISTRY=dockercoins TAG=v0.1

  (this will expand $REGISTRY/worker:$TAG to dockercoins/worker:v0.1)

k8s/buildshiprun-dockerhub.md

Running our application on Kubernetes

• We can now deploy our code (as well as a redis instance)

k8s/ourapponkube.md

Is this working?

• After waiting for the deployment to complete, let's look at the logs!

  (Hint: use kubectl get deploy -w to watch deployment events)

Connecting containers together

• Three deployments need to be reachable by others: hasher, redis, rng

• worker doesn't need to be exposed

• webui will be dealt with later

k8s/ourapponkube.md

Is this working yet?

• The worker has an infinite loop, that retries 10 seconds after an error

Exposing services for external access

• Now we would like to access the Web UI

• We will expose it with a NodePort

  (just like we did for the registry)

k8s/ourapponkube.md

Accessing the web UI

• We can now connect to any node, on the allocated node port, to view the web UI

Accessing the API with kubectl proxy

• The API requires us to authenticate¹

• There are many authentication methods available, including:

  • TLS client certificates
    (that's what we've used so far)

  • HTTP basic password authentication
    (from a static file; not recommended)

  • various token mechanisms
    (detailed in the documentation)

¹OK, we lied. If you don't authenticate, you are considered to be user system:anonymous, which doesn't have any access rights by default.

k8s/kubectlproxy.md

Accessing the API directly

• Let's see what happens if we try to access the API directly with curl

The API will tell us that user system:anonymous cannot access this path.

k8s/kubectlproxy.md

Authenticating to the API

If we wanted to talk to the API, we would need to:

• extract our TLS key and certificate information from ~/.kube/config

  (the information is in PEM format, encoded in base64)

• use that information to present our certificate when connecting

  (for instance, with openssl s_client -key ... -cert ... -connect ...)

• figure out exactly which credentials to use

  (once we start juggling multiple clusters)

• change that whole process if we're using another authentication method

🤔 There has to be a better way!

k8s/kubectlproxy.md

Using kubectl proxy for authentication

• kubectl proxy runs a proxy in the foreground

• This proxy lets us access the Kubernetes API without authentication

  (kubectl proxy adds our credentials on the fly to the requests)

• This proxy lets us access the Kubernetes API over plain HTTP

• This is a great tool to learn and experiment with the Kubernetes API

• ... And for serious uses as well (suitable for one-shot scripts)

• For unattended use, it's better to create a service account

k8s/kubectlproxy.md

Trying kubectl proxy

• Let's start kubectl proxy and then do a simple request with curl!

The output is a list of available API routes.

k8s/kubectlproxy.md

kubectl proxy is intended for local use

• By default, the proxy listens on port 8001

  (But this can be changed, or we can tell kubectl proxy to pick a port)

• By default, the proxy binds to 127.0.0.1

  (Making it unreachable from other machines, for security reasons)

• By default, the proxy only accepts connections from:

  ^localhost$,^127\.0\.0\.1$,^\[::1\]$

• This is great when running kubectl proxy locally

• Not-so-great when you want to connect to the proxy from a remote machine

k8s/kubectlproxy.md

Running kubectl proxy on a remote machine

• If we wanted to connect to the proxy from another machine, we would need to:

  • bind to INADDR_ANY instead of 127.0.0.1

  • accept connections from any address

• This is achieved with:

  kubectl proxy --port=8888 --address=0.0.0.0 --accept-hosts=.*

Do not do this on a real cluster: it opens full unauthenticated access!

k8s/kubectlproxy.md

Security considerations

• Running kubectl proxy openly is a huge security risk

• It is slightly better to run the proxy where you need it

  (and copy credentials, e.g. ~/.kube/config, to that place)

• It is even better to use a limited account with reduced permissions

k8s/kubectlproxy.md

Good to know ...

• kubectl proxy also gives access to all internal services

• Specifically, services are exposed as such:

  /api/v1/namespaces/<namespace>/services/<service>/proxy

• We can use kubectl proxy to access an internal service in a pinch

  (or, for non HTTP services, kubectl port-forward)

• This is not very useful when running kubectl directly on the cluster

  (since we could connect to the services directly anyway)

• But it is very powerful as soon as you run kubectl from a remote machine

k8s/kubectlproxy.md

Controlling the cluster remotely

• All the operations that we do with kubectl can be done remotely

• In this section, we are going to use kubectl from our local machine

k8s/localkubeconfig.md

Requirements

The exercises in this chapter should be done on your local machine.

• kubectl is officially available on Linux, macOS, Windows

  (and unofficially anywhere we can build and run Go binaries)

• You may skip these exercises if you are following along from:

  • a tablet or phone

  • a web-based terminal

  • an environment where you can't install and run new binaries

k8s/localkubeconfig.md

Installing kubectl

• If you already have kubectl on your local machine, you can skip this

Note: if you are following along with a different platform (e.g. Linux on an architecture different from amd64, or with a phone or tablet), installing kubectl might be more complicated (or even impossible) so feel free to skip this section.

k8s/localkubeconfig.md

Testing kubectl

• Check that kubectl works correctly

  (before even trying to connect to a remote cluster!)

The output should look like this:

Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.0",
GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean",
BuildDate:"2019-03-25T15:53:57Z", GoVersion:"go1.12.1", Compiler:"gc",
Platform:"linux/amd64"}

k8s/localkubeconfig.md

Preserving the existing ~/.kube/config

• If you already have a ~/.kube/config file, rename it

  (we are going to overwrite it in the following slides!)

• If you never used kubectl on your machine before: nothing to do!

k8s/localkubeconfig.md

Copying the configuration file from node1

• The ~/.kube/config file that is on node1 contains all the credentials we need

• Let's copy it over!

k8s/localkubeconfig.md

Updating the server address

• There is a good chance that we need to update the server address

• To know if it is necessary, run kubectl config view

• Look for the server: address:

  • if it matches the public IP address of node1, you're good!

  • if it is anything else (especially a private IP address), update it!

• To update the server address, run:

  kubectl config set-cluster kubernetes --server=https://X.X.X.X:6443
  # Make sure to replace X.X.X.X with the IP address of node1!

k8s/localkubeconfig.md

Checking that we can connect to the cluster

• We can now run a couple of trivial commands to check that all is well

We can now utilize the cluster exactly as we did before, except that it's remote.

k8s/localkubeconfig.md

Accessing internal services

• When we are logged in on a cluster node, we can access internal services

  (by virtue of the Kubernetes network model: all nodes can reach all pods and services)

• When we are accessing a remote cluster, things are different

  (generally, our local machine won't have access to the cluster's internal subnet)

• How can we temporarily access a service without exposing it to everyone?

Suspension of disbelief

The exercises in this section assume that we have set up kubectl on our local machine in order to access a remote cluster.

We will therefore show how to access services and pods of the remote cluster, from our local machine.

You can also run these exercises directly on the cluster (if you haven't installed and set up kubectl locally).

Running commands locally will be less useful (since you could access services and pods directly), but keep in mind that these commands will work anywhere as long as you have installed and set up kubectl to communicate with your cluster.

k8s/accessinternal.md

kubectl proxy in theory

• Running kubectl proxy gives us access to the entire Kubernetes API

• The API includes routes to proxy HTTP traffic

• These routes look like the following:

  /api/v1/namespaces/<namespace>/services/<service>/proxy

• We just add the URI to the end of the request, for instance:

  /api/v1/namespaces/<namespace>/services/<service>/proxy/index.html

• We can access services and pods this way

k8s/accessinternal.md

kubectl proxy in practice

• Let's access the webui service through kubectl proxy

k8s/accessinternal.md

kubectl port-forward in theory

• What if we want to access a TCP service?

• We can use kubectl port-forward instead

• It will create a TCP relay to forward connections to a specific port

  (of a pod, service, deployment...)

• The syntax is:

  kubectl port-forward service/name_of_service local_port:remote_port

• If only one port number is specified, it is used for both local and remote ports

k8s/accessinternal.md

kubectl port-forward in practice

• Let's access our remote Redis server

k8s/accessinternal.md

The Kubernetes dashboard

• Kubernetes resources can also be viewed with a web dashboard

• That dashboard is usually exposed over HTTPS

  (this requires obtaining a proper TLS certificate)

• Dashboard users need to authenticate

• We are going to take a dangerous shortcut

k8s/dashboard.md

The insecure method

• We could (and should) use Let's Encrypt ...

• ... but we don't want to deal with TLS certificates

• We could (and should) learn how authentication and authorization work ...

• ... but we will use a guest account with admin access instead

Yes, this will open our cluster to all kinds of shenanigans. Don't do this at home.

k8s/dashboard.md

Running a very insecure dashboard

• We are going to deploy that dashboard with one single command

• This command will create all the necessary resources

  (the dashboard itself, the HTTP wrapper, the admin/guest account)

• All these resources are defined in a YAML file

• All we have to do is load that YAML file with with kubectl apply -f

k8s/dashboard.md

Connecting to the dashboard

You'll want the 3xxxx port.

The dashboard will then ask you which authentication you want to use.

k8s/dashboard.md

Dashboard authentication

• We have three authentication options at this point:

  • token (associated with a role that has appropriate permissions)

  • kubeconfig (e.g. using the ~/.kube/config file from node1)

  • "skip" (use the dashboard "service account")

• Let's use "skip": we're logged in!

Running the Kubernetes dashboard securely

• The steps that we just showed you are for educational purposes only!

• If you do that on your production cluster, people can and will abuse it

• For an in-depth discussion about securing the dashboard,
  check this excellent post on Heptio's blog

k8s/dashboard.md

Security implications of kubectl apply

• When we do kubectl apply -f <URL>, we create arbitrary resources

• Resources can be evil; imagine a deployment that ...

kubectl apply is the new curl | sh

• curl | sh is convenient

• It's safe if you use HTTPS URLs from trusted sources

Scaling our demo app

• Our ultimate goal is to get more DockerCoins

  (i.e. increase the number of loops per second shown on the web UI)

• Let's look at the architecture again:

  

• The loop is done in the worker; perhaps we could try adding more workers?

k8s/scalingdockercoins.md

Adding another worker

• All we have to do is scale the worker Deployment

After a few seconds, the graph in the web UI should show up.

k8s/scalingdockercoins.md

Adding more workers

• If 2 workers give us 2x speed, what about 3 workers?

The graph in the web UI should go up again.

(This is looking great! We're gonna be RICH!)

k8s/scalingdockercoins.md

Adding even more workers

• Let's see if 10 workers give us 10x speed!

Why are we stuck at 10 hashes per second?

• If this was high-quality, production code, we would have instrumentation

  (Datadog, Honeycomb, New Relic, statsd, Sumologic, ...)

• It's not!

• Perhaps we could benchmark our web services?

  (with tools like ab, or even simpler, httping)

k8s/scalingdockercoins.md

Benchmarking our web services

• We want to check hasher and rng

• We are going to use httping

• It's just like ping, but using HTTP GET requests

  (it measures how long it takes to perform one GET request)

• It's used like this:

  httping [-c count] http://host:port/path

• Or even simpler:

  httping ip.ad.dr.ess

• We will use httping on the ClusterIP addresses of our services

k8s/scalingdockercoins.md

Obtaining ClusterIP addresses

• We can simply check the output of kubectl get services

• Or do it programmatically, as in the example below

Now we can access the IP addresses of our services through $HASHER and $RNG.

k8s/scalingdockercoins.md

Checking hasher and rng response times

• hasher is fine (it should take a few milliseconds to reply)

• rng is not (it should take about 700 milliseconds if there are 10 workers)

• Something is wrong with rng, but ... what?

k8s/scalingdockercoins.md

Hasardons-nous à des conclusions hâtives

• Le goulot d'étranglement semble être rng.

• Et si à tout hasard, nous n'avions pas assez d'entropie, et qu'on ne pouvait générer assez de nombres aléatoires?

• On doit escalader le service rng sur plusieurs machines!

Note: ceci est une fiction! Nous avons assez d'entropie. Mais on a besoin d'un prétexte pour monter en charge.

(En réalité, le code de rng exploite /dev/urandom, qui n'est jamais à court d'entropie...)
...et c'est tout aussi bon que /dev/random.) shared/hastyconclusions.md

Daemon sets

• We want to scale rng in a way that is different from how we scaled worker

• We want one (and exactly one) instance of rng per node

• What if we just scale up deploy/rng to the number of nodes?

  • nothing guarantees that the rng containers will be distributed evenly

  • if we add nodes later, they will not automatically run a copy of rng

  • if we remove (or reboot) a node, one rng container will restart elsewhere

• Instead of a deployment, we will use a daemonset

k8s/daemonset.md

Daemon sets in practice

• Daemon sets are great for cluster-wide, per-node processes:

  • kube-proxy

  • weave (our overlay network)

  • monitoring agents

  • hardware management tools (e.g. SCSI/FC HBA agents)

  • etc.

• They can also be restricted to run only on some nodes

k8s/daemonset.md

Creating a daemon set

• Unfortunately, as of Kubernetes 1.14, the CLI cannot create daemon sets

Creating the YAML file for our daemon set

• Let's start with the YAML file for the current rng resource

k8s/daemonset.md

"Casting" a resource to another

• What if we just changed the kind field?

  (It can't be that easy, right?)

Understanding the problem

• The core of the error is:

  error validating data:
  [ValidationError(DaemonSet.spec):
  unknown field "replicas" in io.k8s.api.extensions.v1beta1.DaemonSetSpec,
  ...

Use the --force, Luke

• We could also tell Kubernetes to ignore these errors and try anyway

• The --force flag's actual name is --validate=false

Checking what we've done

• Did we transform our deployment into a daemonset?

deploy/rng and ds/rng

• You can have different resource types with the same name

  (i.e. a deployment and a daemon set both named rng)

• We still have the old rng deployment

  NAME                       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
  deployment.apps/rng        1         1         1            1           18m

• But now we have the new rng daemon set as well

  NAME                DESIRED  CURRENT  READY  UP-TO-DATE  AVAILABLE  NODE SELECTOR  AGE
  daemonset.apps/rng  2        2        2      2           2          <none>         9s

k8s/daemonset.md

Too many pods

• If we check with kubectl get pods, we see:

  • one pod for the deployment (named rng-xxxxxxxxxx-yyyyy)

  • one pod per node for the daemon set (named rng-zzzzz)

  NAME                        READY     STATUS    RESTARTS   AGE
  rng-54f57d4d49-7pt82        1/1       Running   0          11m
  rng-b85tm                   1/1       Running   0          25s
  rng-hfbrr                   1/1       Running   0          25s
  [...]

Is this working?

• Look at the web UI

Labels and selectors

• The rng service is load balancing requests to a set of pods

• That set of pods is defined by the selector of the rng service

• The selector is app=rng

• It means "all the pods having the label app=rng"

  (They can have additional labels as well, that's OK!)

k8s/daemonset.md

Selector evaluation

• We can use selectors with many kubectl commands

• For instance, with kubectl get, kubectl logs, kubectl delete ... and more

But ... why do these pods (in particular, the new ones) have this app=rng label?

k8s/daemonset.md

Where do labels come from?

• When we create a deployment with kubectl create deployment rng,
  this deployment gets the label app=rng

• The replica sets created by this deployment also get the label app=rng

• The pods created by these replica sets also get the label app=rng

• When we created the daemon set from the deployment, we re-used the same spec

• Therefore, the pods created by the daemon set get the same labels

Note: when we use kubectl run stuff, the label is run=stuff instead.

k8s/daemonset.md

Updating load balancer configuration

• We would like to remove a pod from the load balancer

• What would happen if we removed that pod, with kubectl delete pod ...?

Selectors for replica sets and daemon sets

• The "mission" of a replica set is:

  "Make sure that there is the right number of pods matching this spec!"

• The "mission" of a daemon set is:

  "Make sure that there is a pod matching this spec on each node!"

Removing a pod from the load balancer

• Currently, the rng service is defined by the app=rng selector

• The only way to remove a pod is to remove or change the app label

• ... But that will cause another pod to be created instead!

• What's the solution?

Complex selectors

• If a selector specifies multiple labels, they are understood as a logical AND

  (In other words: the pods must match all the labels)

• Kubernetes has support for advanced, set-based selectors

  (But these cannot be used with services, at least not yet!)

k8s/daemonset.md

The plan

1. Add the label enabled=yes to all our rng pods

2. Update the selector for the rng service to also include enabled=yes

3. Toggle traffic to a pod by manually adding/removing the enabled label

4. Profit!

Note: if we swap steps 1 and 2, it will cause a short service disruption, because there will be a period of time during which the service selector won't match any pod. During that time, requests to the service will time out. By doing things in the order above, we guarantee that there won't be any interruption.

k8s/daemonset.md

Adding labels to pods

• We want to add the label enabled=yes to all pods that have app=rng

• We could edit each pod one by one with kubectl edit ...

• ... Or we could use kubectl label to label them all

• kubectl label can use selectors itself