VIRTUALISATION DES RÉSEAUX

Partie 4

K8S

OpenStack

DC Fabric

Nicolas ROHART
nicolas.rohart@outlook.fr
 RÉFÉRENCES
• Sofware Defined Network, A Comprehensive Approach, Paul
Göransson
• SDN: Software Defined Networks, Thomas D. Nadeau and Ken Gray,
O’REILLY
• Foundations of modern networking: SDN, NFV, QoE, IoT, and Cloud,
William Stallings. Addison-Wesley Professional, 2015
• Network Functions Virtualization with a touch of SDN, Rajendra
Chayapathi. Addison-Wesley, 2017

2
 SOMMAIRE

• K8S

• OpenStack

• DC Fabric

3
RAPPEL
 VIRTUALIZATION TECHNIQUE

Hypervisor / VM Container
5
DOCKER
6
K8S
HIGH LEVEL DESIGN

8
K8S FEATURES

9
 MASTER COMPONENTS
• API Server : expose l'API Kubernetes et constitue le frontal du plan de contrôle
Kubernetes.
• etcd : toutes les données du cluster sont stockées dans le stockage etcd et il s'agit d'un
magasin clé-valeur simple, distribué et cohérent. Il est principalement utilisé pour la
configuration partagée et la découverte de services.
• Controller-manager : le gestionnaire de contrôleur exécute des contrôleurs qui gèrent des
tâches de routine dans le cluster, par ex. Contrôleur de réplication, contrôleur de points
de terminaison, etc.
• Scheduler : Le planificateur dispose des informations concernant les ressources
disponibles sur les membres du cluster. Le planificateur surveille également les pods
nouvellement créés auxquels aucun nœud n'est attribué et sélectionne un nœud sur
lequel ils doivent s'exécuter.

11
 NODE COMPONENTS
• kubelet : l'agent de nœud principal qui surveille les pods qui ont été
attribués à son nœud et effectue des actions pour le maintenir en bonne
santé et en bon état de fonctionnement, par ex. monter des volumes de pod,
exécuter des conteneurs, effectuer des vérifications de l'état, etc.
• kube-proxy : active l'abstraction du service Kubernetes en maintenant les
règles du réseau sur l'hôte et en effectuant le transfert de connexion. kube-
proxy agit comme un proxy réseau et un équilibreur de charge pour un
service sur un nœud de travail unique.
• Docker : il est utilisé pour exécuter réellement des conteneurs.

12
 VUE SIMPLIFIÉE

L7 Logic (Ingress)

L3-L4 Networking

L3 – L7 Network
Management ==
Service Mesh

13
KUBE-API-SERVER

14
ETCD

15
 KUBE-SCHEDULER

16
 KUBELET

17
 KUBE PROXY

18
CONTAINER RUNTIME

19
 CNI

20
K8S sur le HW

21
 POD
• Description : POD
• Pod = entité composé de un ou CONTENEUR 1 CONTENEUR 2 CONTENEUR 3
plusieurs conteneurs NGINX Prometheus fluentd
SHARED LOOPBACK (127.0.0.1)
• Un Pod déployé sur un node
• Partage du même namespace
réseau et du point de montage
• Le nombre de conteneurs dans un
pod ne peut pas être réévalué

VOLUMES

22
 POD
• Caractéristiques d’un pod:
• Liste de containers
• Une @IP (ip de contact du POD)
• Un nœud K8S d’appartenance
• Des labels
• Des évènements
• Un statut
• …

23
 LABELS
Les labels permettent d’ajouter des informations permettant de repérer
des objets dans le cluster. Ces labels vont ensuite être utilisés pour
effectuer des sélections.
apiVersion: v1
kind: Pod
Exemples de labels: metadata:
- release: stable name: label-demo
- release: canary labels:
environment: production
- environment: dev app: nginx
- environment: qa spec:
- environment: prod containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
24
 SELECTEURS
Les Sélecteurs permettent de sélectionner des objets parmi un ensemble d’objets.

25
 DEPLOYMENT
L’objet deployment dans K8S permet de manipuler
plus simplement le cycle de vie des pods.
La manipulation des pods pour un environnement de
production peut rapidement se montrer fastidieuse.

26
 SERVICES
Va faire le lien entre le POD en
interne et l’extérieur du Node.

27
CLUSTER IP

28
 HEADLESS
Avec Selecteur
Identique au ClusterIP sauf que le service ne possède pas d’@IP

Les pods sont joignables en direct

29
HEADLESS
SANS SELECTEUR

30
NODE PORT

31
NAMESPACE

32
NAMESPACE

33
 INGRESS
Objet qui permet de configurer automatiquement le reverse proxy de k8s

34
INGRESS

35
ROLLING UPDATE

36
CANARY

37
VOLUME

38
 VOLUME
• emptydir
• hostpath
• persistanceVolumeClaim

39
 BGP

Nicolas ROHART
 AVANTAGES / INCONVÉNIENTS
• Nombre de routes • Optimisation
• Simplicité avec de • Plus complexe à faire
l’automatisation manuellement
• Meilleur isolation (flap)
• Temps de convergence

41
 BASES
• AS
• AS Path
• Local Pref
• Multi exit discriminator (MED)
• Community

42
 BASES

Ici R1 R2 et R3 dans le même AS

43
 ATTENTION

• Risque important de forte dégradation en cas de fausse manipulation :

• Exemple : Aspiration du trafic avec l’annonce d’un mauvais LAN (Pakistan et
YouTube)

44
EQUAL COST MULTIPATH
ROUTING (ECMP)
 BUT
• État : le device de niveau 3 ne choisi qu’une route sur tous les
chemins possible
• Répartition du trafic sur tous les chemins réseau
• Permet d’augmenter fortement la bande passante
• Permet de réduire l’impact d’une coupure

46
EXEMPLE

47
DATA CENTER FABRIC
ÉVOLUTION DU TRAFIC

49
USE CASE

50
SOUCIS D’ARCHITECTURE

51
LEGACY

52
 CONSÉQUENCES

• Surcharge réseau
• Latence
• Failure
• Mauvaise utilisation des ressources

53
CLEFS POUR UN DC

54
 DATA CENTER FABRIC
• E/O trafic vs N/S trafic
• Full bandwidth entre chaque end point
• Minimiser le nombre de connectiques
• Minimiser le nombre de sauts
• Redondance
• Flexible

55
BLOCKING NETWORK

56
NON-BLOCKING NETWORK

57
2 STAGE NETWORK

58
3 STAGE NETWORK

59
CLOS

60
CLOS

61
DC ARCHITECTURE

62
FAT TREE

63
FAT TREE

64
DCELL

65
BCUBE

66
 AVANTAGES CLOS

• Non-Blocking architecture
• Latence constante
• Bandwidth constante
• Résilience avec des chemins alternatifs

67
SCALE OUT

68
BGP & CLOS

69
 BGP & L2 ?

• Problèmes avec le L2 :
• Broadcast Storm
• Compliqué à trouble shooter
• MLAG est un protocole propriétaire
• MLAG limite le nombre de Containers par Leaf

70
MLAG

71
BGP

72
FACEBOOK
POD

74
ARCHITECTURE

75
ARCHITECTURE

76
ARCHITECTURE

77
ARCHITECTURE

78
DATA CENTER

79
FABRIC AGGREGATION

80
FABRIC AGGREGATION

81
F16

82
HGRID

83
HGRID

84
MEGA REGION

85
OPENSTACK

86
 BREF HISTORIQUE
• Fusion de 2 projets en 2010 :
• Rackspace
• NASA
• Les release et code sont validés par OpenStack Foundation
• Les aspects techniques sont validés par OpenStack Technical
Committee

87
 POURQUOI CETTE POPULARITÉ?

• Pas de cout de licence

• Travail communautaire
• Complètement Open Source
• Vendeur indépendant
• N’importe qui peut l’utiliser et le modifier

88
RELEASES ET DÉPLOIEMENT

89
 NODE
OpenStack
OpenStack Cloud 1
Cloud 2
Controller All-in-one
Node

Compute
Compute Network + Storage
Node Node Storage Node
Node

90
ÉTAT DE L’ART

91
 OPENSTACK ARCHITECTURE
Horizon
(GUI Dashboard)

Heat
(Orchestration)

Keystone
(Security and Registry)

Nova Ironic Neutron Cinder Swift

(Compute) (Bare-Metal) (Network) (Storage) (Storage)

92
 HORIZON

• GUI utilise Django

• Accès CLI-tools pour interagir
• Les échanges se font via REST APIs
-> Permet l’interaction avec les modules
(node)

93
 NOVA

• Interagie avec l’hyperviseur

• Facilite la création / suppression / modification des ressources
allouées
• Manage le cycle de vie des VM

94
NOVA

95
 NOVA
Compute worker Network Controller
Compute workers manage computing The Network Controller manages the
instances on host machines. The API networking resources on host
dispatches commands to compute machines. The API server dispatches
workers to complete these tasks: commands through the message
• Run instances queue, which are subsequently
processed by Network Controllers.
• Delete instances (Terminate Specific operations include:
instances) • Allocating fixed IP addresses
• Reboot instances • Configuring VLANs for projects
• Attach volumes • Configuring networks for compute
• Detach volumes nodes
• Get console output

96
 MAGNUM

• Manage et déploie des containers

• Gère le cycle de vie
• Utilise Docker/Swarm ou Kubernetes

97
 IRONIC

• Pour les application ayant besoin de serveur dédié (bare metal) au

lieu d’un environnement partagé
• Permet à OpenStack de supporter des environnements mixte ou
hybrid

98
 NEUTRON

• Facilite le déploiement et la configuration des services réseau

• Gère la config de la connectivité entre les VNF ou plus précisément
les VM et l’extérieur (WAN ou LAN)
• Défini le subnet (block d’@IP), le port avec une IP assignée et un
réseau

99
 NEUTRON
V V V V V V
N N N N N N VNF
F F F F F F

Port

Subnet
Subnet Subnet NFVI
Neutron Network Neutron Network Network

Router
100
 NEUTRON
Create a subnet by Boot the VM
Create Network,
defining @IP range, identifying a vNIC
providing a name
and associated connected to the
for identification
with the network network

Port is deleted and Neutron assigns

Neutron create the
@IP is released @IP to the virtual
virtual port to be
when the VM is port from the
used
destroyed subnet’s pool

101
NEUTRON

102
KEYSTONE

103
KEYSTONE

104
GLANCE
105
 SWIFT

• Object Storage Functionality

• HTTP pour accéder au stockage
• Possibilité de stocker les Data sur n’importe quelle PlateForme

106
 CINDER

• Manage la virtualisation du Block Storage

• Block Storage = catalogue file, database, snapshot
• Protocol NFS (Network File System)

107
 MODULES DE STOCKAGE
File System Storage,
Glance File System Storage with frequent R/W
(Storage)

Swift
Object Storage Persistent Data
(Object
Storage)

Cinder Large Volume Data

(Block Block Storage High performance
Storage)
108
MODULES DE STOCKAGE

109
 MODULES DE STOCKAGE
File Storage Block Storage Object Storage

Add additional persistent storage to Store data, including VM

Used to Run operating system
a virtual machine images
A block device that can be
Accessed through A file system REST API
partitioned, formatted and mounted

Accessible from Within a VM Within a VM Anywhere

OpenStack Compute OpenStack Object

Managed by OpenStack Block Storage (Cinder)
(Nova) Storage (Swift)

Persists until VM is terminated Deleted by user Deleted by user

Administrator configues Amount of available

Sizing determined by Specified by user in initial request
size settings physical storage

110
 CEILOMETER

• Mesure et collecte les statistiques ainsi que l’usage des data

• Les data sont utilisés à des fins de facturation par exemple

111
 HEAT

• Service d’Orchestration
• Défini le déploiement d’une application Cloud
• Tourne dans le Node Controller

112
HEAT

113
 Monitoring Security Orchestration GUI

Ceilometer
(Data Collection)
Keystone
All together
(Security &
Heat
(Orchestration)
Horizon (GUI
Dashboard)
Registry)

OpenStack

Ironic Nova Magnum

Neutron
(Bare-Metal (VM (Container Glance (Network)
compute) compute) compute) (Storage)
Compute Network
Cinder (Block Swift (Object
storage) storage)

Storage
114
ALL TOGETHER
115
116
FLOW

117
EXEMPLE

118
CONCLUSION