pulvérisation cubique
v2.26.0
Si vous avez des questions, consultez la documentation sur kubespray.io et rejoignez-nous sur kubernetes slack, canal #kubespray . Vous pouvez recevoir votre invitation ici
Vous trouverez ci-dessous plusieurs façons d'utiliser Kubespray pour déployer un cluster Kubernetes.
Installez Ansible conformément au guide d'installation d'Ansible, puis exécutez les étapes suivantes :
# Copy ` ` inventory/sample ` ` as ` ` inventory/mycluster ` `
cp -rfp inventory/sample inventory/mycluster
# Update Ansible inventory file with inventory builder
declare -a IPS=(10.10.1.3 10.10.1.4 10.10.1.5)
CONFIG_FILE=inventory/mycluster/hosts.yaml python3 contrib/inventory_builder/inventory.py ${IPS[@]}
# Review and change parameters under ` ` inventory/mycluster/group_vars ` `
cat inventory/mycluster/group_vars/all/all.yml
cat inventory/mycluster/group_vars/k8s_cluster/k8s-cluster.yml
# Clean up old Kubernetes cluster with Ansible Playbook - run the playbook as root
# The option ` --become ` is required, as for example cleaning up SSL keys in /etc/,
# uninstalling old packages and interacting with various systemd daemons.
# Without --become the playbook will fail to run !
# And be mind it will remove the current kubernetes cluster (if it ' s running)!
ansible-playbook -i inventory/mycluster/hosts.yaml --become --become-user=root reset.yml
# Deploy Kubespray with Ansible Playbook - run the playbook as root
# The option ` --become ` is required, as for example writing SSL keys in /etc/,
# installing packages and interacting with various systemd daemons.
# Without --become the playbook will fail to run !
ansible-playbook -i inventory/mycluster/hosts.yaml --become --become-user=root cluster.yml Remarque : lorsqu'Ansible est déjà installé via les packages système sur le nœud de contrôle, les packages Python installés via sudo pip install -r requirements.txt iront dans une autre arborescence de répertoires (par exemple /usr/local/lib/python2.7/dist-packages sur Ubuntu) d'Ansible (par exemple /usr/lib/python2.7/dist-packages/ansible toujours sur Ubuntu). En conséquence, la commande ansible-playbook échouera avec :
ERROR! no action detected in task. This often indicates a misspelled module name, or incorrect module path.
Cela indique probablement qu'une tâche dépend d'un module présent dans requirements.txt .
Une façon de résoudre ce problème consiste à désinstaller le package Ansible du système, puis à réinstaller Ansible via pip , mais cela n'est pas toujours possible et il faut faire attention aux versions des packages. Une solution de contournement consiste à définir les variables d'environnement ANSIBLE_LIBRARY et ANSIBLE_MODULE_UTILS respectivement sur les sous-répertoires ansible/modules et ansible/module_utils de l'emplacement d'installation pip , qui est l' Location indiqué en exécutant pip show [package] avant d'exécuter ansible-playbook .
Un moyen simple de vous assurer que vous obtenez la version correcte d'Ansible consiste à utiliser l'image Docker prédéfinie de Quay. Vous devrez ensuite utiliser des montages de liaison pour accéder à l'inventaire et à la clé SSH dans le conteneur, comme ceci :
git checkout v2.26.0
docker pull quay.io/kubespray/kubespray:v2.26.0
docker run --rm -it --mount type=bind,source="$(pwd)"/inventory/sample,dst=/inventory
--mount type=bind,source="${HOME}"/.ssh/id_rsa,dst=/root/.ssh/id_rsa
quay.io/kubespray/kubespray:v2.26.0 bash
# Inside the container you may now run the kubespray playbooks:
ansible-playbook -i /inventory/inventory.ini --private-key /root/.ssh/id_rsa cluster.yml Voir ici si vous souhaitez utiliser ce référentiel comme collection Ansible
Pour Vagrant, nous devons installer des dépendances Python pour les tâches de provisionnement. Vérifiez que Python et pip sont installés :
python -V && pip -VSi cela renvoie la version du logiciel, vous êtes prêt à partir. Sinon, téléchargez et installez Python à partir d'ici https://www.python.org/downloads/source/
Installez Ansible conformément au guide d'installation d'Ansible, puis exécutez l'étape suivante :
vagrant up Remarque : Les types de système d'exploitation basés sur l'initialisation Upstart/SysV ne sont pas pris en charge.
ansible_become ou les paramètres de commande --become or -b doivent être spécifiés.Matériel : ces limites sont protégées par Kubespray. Les exigences réelles de votre charge de travail peuvent différer. Pour un guide de dimensionnement, consultez le guide Building Large Clusters.
Vous pouvez choisir parmi dix plugins réseau. (par défaut : calico , sauf que Vagrant utilise flannel )
flanelle : mise en réseau gre/vxlan (couche 2).
Calico est un fournisseur de réseaux et de politiques de réseau. Calico prend en charge un ensemble flexible d'options de mise en réseau conçues pour vous offrir la mise en réseau la plus efficace dans une gamme de situations, y compris les réseaux non superposés et superposés, avec ou sans BGP. Calico utilise le même moteur pour appliquer la politique réseau pour les hôtes, les pods et (si vous utilisez Istio et Envoy) les applications au niveau de la couche de maillage de services.
cilium : mise en réseau de couche 3/4 (ainsi que couche 7 pour protéger et sécuriser les protocoles d'application), prend en charge l'insertion dynamique du bytecode BPF dans le noyau Linux pour implémenter les services de sécurité, la mise en réseau et la logique de visibilité.
weave : Weave est un réseau de superposition de conteneurs léger qui ne nécessite pas de cluster de base de données K/V externe. (Veuillez vous référer à la documentation de dépannage weave ).
kube-ovn : Kube-OVN intègre la virtualisation de réseau basée sur OVN avec Kubernetes. Il offre une structure de réseau de conteneurs avancée pour les entreprises.
kube-router : Kube-router est un CNI L3 pour la mise en réseau Kubernetes visant à fournir une simplicité opérationnelle et des performances élevées : il utilise IPVS pour fournir le proxy de services Kube (si configuré pour remplacer kube-proxy), iptables pour les politiques réseau et BGP pour les ods. Mise en réseau L3 (avec éventuellement un peering BGP avec des homologues BGP hors cluster). Il peut également éventuellement annoncer des routes vers les CIDR, ClusterIP, ExternalIP et LoadBalancerIP des pods du cluster Kubernetes.
macvlan : Macvlan est un pilote réseau Linux. Les pods ont leur propre adresse Mac et IP unique, connectés directement au réseau physique (couche 2).
multus : Multus est un plugin méta CNI qui fournit une prise en charge de plusieurs interfaces réseau aux pods. Pour chaque interface, Multus délègue les appels CNI à des plugins CNI secondaires tels que Calico, macvlan, etc.
custom_cni : Vous pouvez spécifier certains manifestes qui seront appliqués aux clusters pour vous apporter votre propre CNI et utiliser ceux non pris en charge par Kubespray. Voir tests/files/custom_cni/README.md et tests/files/custom_cni/values.yaml pour un exemple avec un CNI fourni par un Helm Chart.
Le plugin réseau à utiliser est défini par la variable kube_network_plugin . Il existe également une option permettant de tirer parti du réseau du fournisseur de cloud intégré. Voir également Vérificateur de réseau.
nginx : le contrôleur d'entrée NGINX.
metallb : le fournisseur de services sans système d'exploitation MetalLB LoadBalancer.
Tests CI/end-to-end sponsorisés par : CNCF, Equinix Metal, OVHcloud, ELASTX.
Voir la matrice de test pour plus de détails.
