Si tiene preguntas, consulte la documentación en kubespray.io y únase a nosotros en el canal de kubernetes slack #kubespray . Puedes obtener tu invitación aquí.
A continuación se muestran varias formas de utilizar Kubespray para implementar un clúster de Kubernetes.
Instale Ansible de acuerdo con la guía de instalación de Ansible y luego ejecute los siguientes pasos:
# 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
Nota: Cuando Ansible ya está instalado a través de paquetes del sistema en el nodo de control, los paquetes de Python instalados mediante sudo pip install -r requirements.txt
irán a un árbol de directorios diferente (por ejemplo, /usr/local/lib/python2.7/dist-packages
en Ubuntu) de Ansible (por ejemplo, /usr/lib/python2.7/dist-packages/ansible
todavía en Ubuntu). Como consecuencia, el comando ansible-playbook
fallará con:
ERROR! no action detected in task. This often indicates a misspelled module name, or incorrect module path.
Esto probablemente indica que una tarea depende de un módulo presente en requirements.txt
.
Una forma de solucionar este problema es desinstalar el paquete Ansible del sistema y luego reinstalar Ansible mediante pip
, pero esto no siempre es posible y hay que tener cuidado con las versiones de los paquetes. Una solución alternativa consiste en configurar las variables de entorno ANSIBLE_LIBRARY
y ANSIBLE_MODULE_UTILS
respectivamente en los subdirectorios ansible/modules
y ansible/module_utils
de la ubicación de instalación pip
, que es la Location
que se muestra al ejecutar pip show [package]
antes de ejecutar ansible-playbook
.
Una forma sencilla de asegurarse de obtener la versión correcta de Ansible es utilizar la imagen acoplable prediseñada de Quay. Luego necesitarás usar montajes de enlace para acceder al inventario y a la clave SSH en el contenedor, así:
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
Consulte aquí si desea utilizar este repositorio como una colección de Ansible.
Para Vagrant necesitamos instalar dependencias de Python para las tareas de aprovisionamiento. Verifique que Python
y pip
estén instalados:
python -V && pip -V
Si esto devuelve la versión del software, estás listo para comenzar. De lo contrario, descargue e instale Python desde aquí https://www.python.org/downloads/source/
Instale Ansible de acuerdo con la guía de instalación de Ansible y luego ejecute el siguiente paso:
vagrant up
Nota: Los tipos de sistema operativo basados en inicio Upstart/SysV no son compatibles.
ansible_become
o los parámetros del comando --become or -b
.Hardware: estos límites están protegidos por Kubespray. Los requisitos reales para su carga de trabajo pueden diferir. Para obtener una guía de tamaño, consulte la guía Creación de grupos grandes.
Puede elegir entre diez complementos de red. (predeterminado: calico
, excepto que Vagrant usa flannel
)
franela: redes gre/vxlan (capa 2).
Calico es un proveedor de políticas de redes y redes. Calico admite un conjunto flexible de opciones de red diseñadas para brindarle la red más eficiente en una variedad de situaciones, incluidas redes superpuestas y no superpuestas, con o sin BGP. Calico usa el mismo motor para aplicar la política de red para hosts, pods y (si usa Istio y Envoy) aplicaciones en la capa de malla de servicio.
cilium: redes de capa 3/4 (así como capa 7 para proteger y proteger los protocolos de aplicaciones), admite la inserción dinámica de código de bytes BPF en el kernel de Linux para implementar servicios de seguridad, redes y lógica de visibilidad.
weave: Weave es una red de superposición de contenedores liviana que no requiere un clúster de base de datos K/V externo. (Consulte la documentación de solución de problemas weave
).
kube-ovn: Kube-OVN integra la virtualización de red basada en OVN con Kubernetes. Ofrece una estructura de red de contenedores avanzada para empresas.
kube-router: Kube-router es un CNI L3 para redes Kubernetes que tiene como objetivo proporcionar simplicidad operativa y alto rendimiento: utiliza IPVS para proporcionar Kube Services Proxy (si está configurado para reemplazar kube-proxy), iptables para políticas de red y BGP para ods. Redes L3 (con emparejamiento BGP opcional con pares BGP fuera del clúster). Opcionalmente, también puede anunciar rutas a los CIDR, ClusterIP, ExternalIP y LoadBalancerIP de los Pods del clúster de Kubernetes.
macvlan: Macvlan es un controlador de red de Linux. Los pods tienen su propia dirección IP y Mac única, conectadas directamente a la red física (capa 2).
multus: Multus es un complemento meta CNI que proporciona soporte de múltiples interfaces de red para pods. Para cada interfaz, Multus delega llamadas CNI a complementos CNI secundarios como Calico, macvlan, etc.
custom_cni: puede especificar algunos manifiestos que se aplicarán a los clústeres para brindarle su propio CNI y utilizar los que no son compatibles con Kubespray. Consulte tests/files/custom_cni/README.md
y tests/files/custom_cni/values.yaml
para ver un ejemplo con un CNI proporcionado por un Helm Chart.
El complemento de red a utilizar está definido por la variable kube_network_plugin
. También existe la opción de aprovechar la red de proveedores de nube integrada. Consulte también Comprobador de red.
nginx: el controlador de ingreso NGINX.
metallb: el proveedor de LoadBalancer del servicio bare-metal de MetalLB.
Pruebas CI/de extremo a extremo patrocinadas por: CNCF, Equinix Metal, OVHcloud, ELASTX.
Consulte la matriz de prueba para obtener más detalles.