Home Articles techniques Implémenter Edgio Delivery CDN en tant que fournisseur d’entrée dans votre cluster Kubernetes
Applications

Implémenter Edgio Delivery CDN en tant que fournisseur d’entrée dans votre cluster Kubernetes

About The Author

Outline

Avant-propos

Voici un exemple d’intégration de Kubernetes avec le service CDN Edgio Delivery pour les praticiens Kubernetes expérimentés. Il suppose un niveau de connaissance de Kubernetes et une connaissance des protocoles Internet standard tels que TCP, DNS et HTTP/HTTPS. L’objectif final est de démontrer un moyen de faire apparaître le service CDN Edgio Delivery comme un service d’entrée standard. L’utilisateur Kubernetes peut maintenir la configuration d’entrée dans des systèmes familiers tels que Portainer ou Terraform.

Kubernetes

Kubernetes.io définit Kubernetes comme « un système open-source pour automatiser le déploiement, la mise à l’échelle et la gestion d’applications conteneurisées ». Il existe plusieurs façons d’afficher un cluster. Le moyen le plus rapide et le plus simple consiste à tirer parti de l’un des nombreux fournisseurs de cloud qui permettent des déploiements en « un clic ».

Les clusters Kubernetes contiennent de nombreuses parties. Dans la démo, nous nous concentrerons sur un sous-ensemble du total.

Pièces Kubernetes

  • Nœud : machine ou machine virtuelle hébergeant les charges de travail et les services.
  • Charge de travail : application simple ou complexe
  • Pod : conteneurs dans lesquels le logiciel d’application s’exécute. Un ou plusieurs pods constituent une charge de travail.
  • Service : mécanisme qui expose une charge de travail à d’autres charges de travail ou entrées
  • Ingress : un mécanisme pour exposer les services au monde extérieur

Edgio

Edgio rend la vie connectée plus rapide, plus sûre et plus simple à gérer en offrant une vitesse, une sécurité et une simplicité inégalées à la périphérie grâce à nos solutions de diffusion, d’applications et de streaming parfaitement intégrées. Notre technologie et nos services d’experts à l’échelle mondiale alimentent les plus grandes marques du monde avec la capacité de fournir l’éducation, le divertissement, les événements et, le plus rapide, le plus dynamique et sans friction applications à chaque utilisateur. Dédié à fournir un service client inégalé et à étendre la valeur à chaque étape du processus, Edgio est un partenaire de choix, générant du trafic Internet mondial pour soutenir les émissions les plus populaires, les films, les sports, les jeux et la musique, et les sites Web à chargement instantané.

Architecture

Edgio Delivery CDN

Pour cette démo, nous utilisons le SDK python Edgio sur GitHub – llnw/llnw-sdk-python : Limelight Networks Python SDK. La configuration de base restera simple.

Lors de la configuration du CDN, les éléments de données suivants (autres que l’authentification) sont nécessaires.

  • Shortname : un identifiant unique dans Edgio Delivery CDN qui contient les règles CDN.
  • Nom d’hôte publié : le nom d’hôte qui fait face à Internet à partir du CDN. Dans le cas de cette démo, le nom d’hôte cstradtman.s.llnwi.net a été préalablement configuré.
  • Chemin de l’URL publiée : chemin mappé dans la règle spécifique en question.
  • Nom d’hôte source : nom d’hôte de l’origine. Dans ce cas, un enregistrement circulaire pointe vers le cluster Kubernetes.
  • Chemin de l’URL source : chemin de destination associé au nom d’hôte. Dans ce cas, il sera vide puisque nous le décrirons plus loin dans ce document. Dans cette démonstration, les charges de travail seront différenciées par numéro de port et non par chemin.

DNS

La démo utilise l’API Vultr DNS. Configurer le CDN en utilisant les adresses IP comme origines n’est pas une bonne pratique. La démo utilise une API pour créer ou modifier un round-Robin dans Un enregistrement pointant vers les nœuds de cluster.

Cluster

La démo est en Vultr sur un cluster à trois nœuds.

Espaces de noms

La démo existera sous l’espace de noms par défaut car c’est la seule chose qui fonctionne sur ce cluster

Nœuds

  • Cluster VKE – 3 nœuds chacun avec
    • Vérin 4G.
    • Disque 80G.
    • 2 vCPU
    • Réseau 1 G.

Charges de travail

La charge de travail est un programme Python simple qui renvoie des informations de base sur la connexion HTTP. Nous déployons cette démo en ligne, ce qui n’est pas une méthode de déploiement typique. Cependant, cela permet à la démo d’être entièrement autonome plutôt que d’avoir des dépendances externes pour construire les conteneurs et les stocker. Le code source figure à l’annexe 1. Le code Python réel est en italique, et le code YAML décrivant le déploiement ne l’est pas. La charge de travail utilise le port TCP 8000.

Services

Plusieurs types de service sont disponibles. Nous utilisons le type de service « NodePort ». Il expose le service sur les adresses IP externes du cluster sur un numéro de port élevé sélectionné aléatoirement. Kubernetes se charge de la connexion à un nœud sur lequel la charge de travail s’exécute.

Entrée

Kubernetes Ingress est un objet logiciel qui décrit le comportement d’un ensemble de ressources qui rendent un service Kubernetes disponible en dehors du cluster.

Un contrôleur d’entrée combine un logiciel et/ou un matériel qui instancie l’objet logiciel d’entrée.

Un CDN est un proxy inverse distribué riche en fonctionnalités, outre la fonction de proxy inverse, les CDN ont généralement des algorithmes de cache flexibles, une diversité géographique, des fonctionnalités de sécurité (ACL (GEO, méthode, regex), des pare-feu d’applications Web, des filigranes, et d’autres fonctionnalités plus avancées que l’on ne trouve pas dans les proxies inverses simples.

Les API pour la surveillance des objets Kubernetes sont bien définies, et un certain nombre de proxys inverses HTTP et d’équilibreurs de charge ont été étendus pour fonctionner en tant que contrôleurs d’entrée. Par exemple, NGINX et HAProxy sont des proxys Old School qui ont été étendus pour fonctionner comme contrôleurs d’entrée et ceux comme Traefik et Itsio ont été développés en parallèle à Kubernetes . Un CDN est une progression naturelle à partir de simples proxies inverses. Dans le cas de cette démo, nous allons créer un contrôleur d’entrée personnalisé qui contrôle Edgio Delivery CDN. Les données généralement requises pour décrire une entrée sont

  • Nom d’hôte public : le nom d’hôte sur lequel le service Kubernetes sera disponible
  • Chemin public : chemin associé au nom d’hôte public sur lequel les services Kubernetes seront disponibles
  • Nom du service backend : nom-service défini par une strophe Kubernetes services
  • Port back-end : nom correspondant à la description du port dans la description du service

Mappages de ressources CDN Edgio Delivery :

Kubernetes

Edgio Delivery CDN

Nom d’hôte public

Nom d’hôte publié

Chemin public

Chemin de l’URL publiée

Nom du service back-end

Unique au sein du cluster Kubernetes

Non connu/disponible pour le monde extérieur

Nom d’hôte source

Nom de domaine complet

Pas vraiment un à un

La logique derrière elle est:

  • Ecoutez l’événement d’entrée de l’espace de noms à partir du cluster
  • Si le type d’événement est « ajouté ».
    • Obtenez l’adresse IP des nœuds du cluster
    • Créer un enregistrement DNS dans vultr
    • Créez des règles CDN dans Edgio CDN pointant vers les enregistrements DNS créés et le port alloué par le service NodePort.
  • Si le type d’événement est « modifié ».
    • Recherchez les règles CDN dans Edgio CDN qui correspondent à l’entrée existante
    • Modifiez les règles dans Edgio CDN pour refléter les nouvelles données dans l’événement
  • Si le type d’événement est “supprimé”.
    • Recherchez les règles CDN dans Edgio CDN qui correspondent à l’entrée supprimée
    • Supprimez les enregistrements DNS dans Vultr associés à cette entrée
    • Supprimez les règles CDN dans Edgio qui correspondent à l’entrée supprimée

Configuration

Objets

Les objets Kubernetes sont décrits dans les fichiers YAML . Dans Kubernetes, chaque configuration est un objet. Vous pouvez placer toutes les configurations de déploiement dans un seul fichier. Il est courant de les diviser en fonction de la partie du déploiement qu’ils décrivent.

Déploiement

Dans l’annexe 1, il y a un grand fichier YAML qui est une combinaison de code Python et YAML. Tout ce qui suit « spec.template.spec.containers.command” » est le code Python qui est transformé en conteneur pendant le déploiement. Du point de vue de l’objet Kubernetes, les lignes qui sont importantes pour nous pour la démo sont:

  • Kind : déploiement – décrit l’objet comme un déploiement
  • Metadata.name : le nom est utilisé par l’objet service pour créer le lien entre les deux.
  • Spec.selector.matchlabels.app: indique à quels pods le déploiement s’appliquera.
  • SPEC.template.spec.containers.image : pointe vers l’image officielle python 3 du hub docker
  • Spec.template.spec.containers.ports.name : une étiquette pour le port à référencer dans le service d’autres objets dans ce cas
  • SPEC.template.spec.containers.ports.containerport : répertorie le port TCP exposé à partir du conteneur en cours d’exécution

Service

  • Kind : déploiement – décrit l’objet comme un déploiement
  • Metadata.name : le nom est utilisé par l’objet Ingress pour créer le lien entre les deux.
  • Spec.selector.app: pointe vers le nom du déploiement – pywai-inline-service tel que nommé dans l’objet de déploiement.
  • Spec.selector.type: Nodeport Ceci définit ce service comme type Nodeport comme décrit ci-dessus
  • Spec.ports.name : l’étiquette pour le port à référencer par d’autres objets (entrée dans ce cas)
  • Spec.ports.protocol: définit le protocole IP utilisé – TCP
  • SPEC.port.port : définit le port exposé par ce service
  • SPEC.ports.targetPort : pointe vers le port exposé par le déploiement – pywai-inline-deployment dans ce cas

Entrée

Dans l’annexe 3, vous verrez le fichier YAML décrivant l’objet Kubernetes pour le contrôleur d’entrée Edgio. Les objets concernés sont les suivants:

  • Kind : Ingress – Ceci indique à Kubernetes qu’il s’agit d’un objet Ingress
  • Medatdata.name – tout dans Kubernetes doit avoir un nom
  • Metadata.labels.cdn – cette balise est utilisée pour signaler au contrôleur d’entrée que cet objet est destiné au contrôleur d’entrée edgio
  • Spec.rules.host – Nom d’hôte public pour exposer le service.
  • Spec.rules.http.paths.path – chemin associé au service.
  • Spec.rules.http.paths.backend.service.name – étiquette du service à exposer
  • Spec.rules.http.paths.backend.service.port.name – étiquette du port du service à exposer

Config. Cartes

Secrets

Kubernetes intègre un concept de secrets pour le stockage des données sensibles. Cette démo exploite ceci pour les noms d’utilisateur et les clés partagées pour Edgio SDK et l’API Vultr DNS

Exemples de code

Le code de cette démonstration inclus dans le git repos

Ajouts et améliorations futurs à la conception actuelle

Dans un prochain post, nous montrerons comment exploiter d’autres solutions Edgio comme par exemple applications. Nous pourrions utiliser le cluster Kubernetes pour exploiter et synchroniser les configurations entre plusieurs offres CDN Edgio pour différents flux de travail.

Annexe 1 – pywai-inline-deployment.yaml

ApiVersion : apps/v1

Type : déploiement

métadonnées :

nom : pywai-inline-deployment

spéc. :

sélecteur :

MatchLabels :

app : pywai-inline-deployment

répliques : 1

modèle :

métadonnées :

étiquettes :

app : pywai-inline-deployment

spéc. :

conteneurs :

– nom : python

image : python:3

commande :

– /bin/sh

– “-c”

– |

cat > /test.py <<EOF

#!/usr/bin/env python3

“””

Serveur HTTP très simple en python pour la journalisation des requêtes

Utilisation :

./server.py [<port>]

“””

Depuis http.server, importez BaseHTTPRequestHandler, HTTPServer

importer la journalisation

importer pprint

Classe S (BaseHTTPRequestHandler) :

def _set_response(self) :

self.send_response(200)

self.send_header(‘Content-type’, « text/html »)

self.end_headers()

def do_GET(self) :

logging.info(“GET requête,\nPath : %s\nHeaders:\n%s\n”, str(self.path), str(pprint.pformat(self.headers)))

self._set_response()

headerinfo=pprint.pformat(self.headers.items())

clientinfo=pprint.pformat(auto.adresse_client)

lineinfo=pprint.pformat(self.requestline)

versioninfo=pprint.pformat(self.request_version)

self.wfile.write(“<pre> {} </pre>”.format(headerinfo).encode(“utf-8”))

self.wfile.write(“<pre> {} </pre>”.format(clientinfo).encode(“utf-8”))

self.wfile.write(“<pre> {} </pre>”.format(lineinfo).encode(“utf-8”))

self.wfile.write(“<pre> {} </pre>”.format(versioninfo).encode(“utf-8”))

def run(Server_class=HTTPServer, handler_class=S, port=8080) :

Logging.basicConfig(level=logging.INFO)

adresse_serveur = (”, port)

httpd = classe_serveur(adresse_serveur, classe_gestionnaire)

logging.info(‘Starting httpd…\n’)

essayez :

httpd.serve_forever()

Sauf KeyboardInterrupt :

réussi

httpd.server_close()

logging.info(‘Stopping httpd…\n’)

si __name__ == «__main__»:

depuis sys import argv

si len(argv) == 2:

run(port=int(argv[1]))

sinon :

run()

EOF

exécutez python /test.py 8000

ports :

– nom : http

ContainerPort : 8000

Annexe 2 – pywai-inline-service.yaml

ApiVersion : v1

Type : Service

métadonnées :

nom : pywai-inline-service

spéc. :

sélecteur :

app : pywai-inline-deployment

Type : NodePort

ports :

– nom : http

protocole : TCP

port : 80

TargetPort : 8000

Annexe 3 – pywai-edgio-Ingress.yaml

ApiVersion : networking.k8s.io/v1

Type : entrée

métadonnées :

nom : external-pywai-inline-ingress

annotations :

kubernetes.io/ingress.class : edgio

étiquettes :

cdn : edgio

spéc. :

règles :

– Hôte : <Entrez le nom abrégé unique>.s.llnwi.net

http :

chemins :

– chemin : /fred

PathType : exact

backend :

service :

nom : external-pywai-inline-service

port :

nom : pywai-port