Crear un cluster Kubernetes en Fedora
|
Esta página analiza fuentes de software de terceros que no están afiliadas ni respaldadas oficialmente por el Proyecto Fedora. Úselas a su propia discreción. Fedora recomienda el uso de software libre y de código abierto, y evitar el software protegido por patentes. |
Creación de un clúster de Kubernetes con kubeadm usando rpms de Fedora
kubeadmDebajo está una guía para crear un cluster Kubernete funcional sobre una máquina Fedora que es apropiada como un entorno de aprendizaje y exploración. Esta guía no se intenta crear un entorno de producción.
La guía de abajo generalmente sigue y propone sustancialmente desde la guía Crear un clúster con kubeadm creada por el equipo de Kubernetes.
Fedora 41 has both versioned and unversioned (v1.29) Kubernetes rpms. Kubernetes 1.29 is no longer supported by the Kubernetes community.
-
Actualiza el sistema con DNF. Reinicia si es necesario, sin embargo un reinicio puede ser diferido hasta tras el siguiente paso.
$ sudo dnf update -
Desactivar el intercambio. El proceso de instalación de kubeadm generará una advertencia si se detecta el intercambio (consulte este ticket para más detalles). En un entorno de aprendizaje y laboratorio, puede ser más fácil desactivar el intercambio. El intercambio se puede dejar activado si se desea y kubeadm está configurado para no detenerse si se detecta. Los sistemas Fedora modernos usan zram por defecto. Reinicie después de desactivar el intercambio.
$ sudo systemctl stop swap-create@zram0 $ sudo dnf remove zram-generator-defaults $ sudo reboot now -
SELinux. La mayoría de las guías para instalar Kubernetes en Fedora recomiendan deshabilitar SELinux. Kubernetes funcionará correctamente con SELinux habilitado y muchos contenedores funcionarán correctamente. Si surgen problemas, deshabilitar SELinux podría ser una opción. Consulte the Quick Doc SELinux guide to changing SELinux states para obtener más información.
-
Deshabilita el cortafuegos. Kubeadm generará una advertencia de instalación si el cortafuegos está en ejecución. Deshabilitar el cortafuegos elimina un origen de complexidad en un entorno de aprendizaje. Los sistemas modernos de Fedora utilizan firewalld.
$ sudo systemctl disable --now firewalldConsulte la sección de Reglas de Cortafuegos en el artículo de Roman Gherta Kubernetes with CRI-O on Fedora 39 para la mejor manera de configurar el cortafuegos de Fedora para trabajar con Kubernetes,
El listado actual de puertos y protocolos utilizados para un cluster Kubernetes puede encontrarse en https://kubernetes.io/docs/reference/networking/ports-and-protocols/.
-
Instala
iptableseiproute-tc. Los paquetes rpm más recientes de Kubernetes incluyen estos paquetes de forma predeterminada.$ sudo dnf install iptables iproute-tc -
Configure el reenvío de IPv4 y los filtros de puente. A continuación, se muestra información copiada del siguiente https://kubernetes.io/docs/setup/production-environment/container-runtimes/
$ sudo cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf overlay br_netfilter EOF -
Cargue los módulos de filtro de superposición y puente.
$ sudo modprobe overlay $ sudo modprobe br_netfilter -
Agregue los parámetros
sysctlrequeridos y persista.# sysctl params required by setup, params persist across reboots $ sudo cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.ipv4.ip_forward = 1 EOF -
Aplica parámetros
sysctlsin un reinicio.$ sudo sysctl --system -
Verifica`br_filter` y se cargan los módulos de superposición..
$ lsmod | grep br_netfilter $ lsmod | grep overlay -
Verifique que las variables del sistema
net.bridge.bridge-nf-call-iptables,net.bridge.bridge-nf-call-ip6tablesynet.ipv4.ip_forwardestén fijadas en1en su configuración de sysctl ejecutando el siguiente comando:$ sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables net.ipv4.ip_forward -
Install a container runtime. CRI-O is installed in this example. Containerd is also an option. Note: If using CRI-O, verify that the major:minor version of cri-o is the same as the version of Kubernetes (installed below). CRI-O rpms are versioned like Kubernetes rpms. Install the CRI-O version that matches the target Kubernetes version.
$ sudo dnf install cri-o1.31 containernetworking-plugins -
Compruebe las versiones de Kubernetes disponibles. Si no está seguro de qué versiones de Kubernetes están disponibles actualmente en Fedora 41 o versiones posteriores, el siguiente comando puede ser útil. En el ejemplo a continuación, los rpms con versiones de Kubernetes 1.29, 1.30, 1.31 y 1.32 están disponibles en Fedora 41. Puede encontrar información actualizada sobre las versiones compatibles y las fechas de finalización en la página Historial de versiones, mantenida por el equipo de Kubernetes.
$ sudo dnf list kubernetes1.??La salida se verá así:
> sudo dnf list kubernetes1.?? Updating and loading repositories: Repositories loaded. Available packages kubernetes1.29.x86_64 1.29.11-2.fc41 updates kubernetes1.30.x86_64 1.30.7-1.fc41 updates kubernetes1.31.x86_64 1.31.3-1.fc41 updates kubernetes1.32.x86_64 1.32.0-1.fc41 updates -
Instalar Kubernetes. En este ejemplo, las tres aplicaciones de Kubernetes (
kubectl,kubeletykubeadm) están instaladas en esta máquina de un solo nodo. Consulte las notas anteriores sobre los paquetes recomendados para el plano de control o los nodos de trabajo si el clúster tendrá ambos tipos de máquinas.$ sudo dnf install kubernetes1.31 kubernetes1.31-kubeadm kubernetes1.31-client -
Inicia y habilita cri-o.
$ sudo systemctl enable --now crio -
Extraiga las imágenes del contenedor del sistema necesarias para Kubernetes. Esto es opcional. El comando
a continuación extraerá las imágenes, si es necesario.kubeadm init$ sudo kubeadm config images pull -
Inicie y habilite
kubelet. Kubelet entrará en un bucle de fallos hasta que se inicialice el clúster en el siguiente paso.$ sudo systemctl enable --now kubelet -
Inicializar el cluster.
$ sudo kubeadm init --pod-network-cidr=10.244.0.0/16 -
kubeadm generará una salida en la terminal que rastrea los pasos de inicialización. Si se ejecuta correctamente, se mostrará la salida a continuación. En este punto, hay un clúster ejecutándose en esta única máquina. Una vez finalizado kubeadm, debería ver:
¡Su plano de control de Kubernetes se ha inicializado correctamente! Para comenzar a usar su clúster, debe ejecutar lo siguiente como usuario normal: mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config Alternativamente, si es el usuario root, puede ejecutar: export KUBECONFIG=/etc/kubernetes/admin.conf -
Los pasos anteriores permiten que un usuario no root use
kubectl, la herramienta de línea de comandos de Kubernetes. Ejecute estos comandos ahora.$ mkdir -p $HOME/.kube $ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config $ sudo chown $(id -u):$(id -g) $HOME/.kube/config -
Permita que la máquina del plano de control también ejecute pods para aplicaciones. De lo contrario, se necesita más de una máquina en el clúster.
$ kubectl taint nodes --all node-role.kubernetes.io/control-plane- -
Instale Flannel en el clúster para proporcionar conectividad de red. Existen muchas otras soluciones de red además de Flannel. Flannel es sencillo y adecuado para esta guía.
$ kubectl apply -f https://github.com/coreos/flannel/raw/master/Documentation/kube-flannel.yml -
Exhibe la lista de los pod en ejecución en el clúster. Todos las vainas exhibirían el estado «En ejecución». Es posible que aparezca el estado CrashLoopBackOff para la vaina coredns. Esto suele ocurrir al instalar Kubernetes en una máquina virtual, cuando el servicio DNS del clúster no selecciona la red adecuada. Utilice su buscador de Internet favorito para encontrar posibles soluciones. Consulte también la sección de solución de problemas a continuación para ver dos posibles soluciones.
$ kubectl get pods --all-namespaces
En este punto hay una sola máquina en el clúster que ejecuta el plano de control y está disponible para trabajar como nodo.
Las mejoras de clústeres de Kubernetes requieren atención y planificación. Consulte el siguiente Mejora de clústeres de kubeadm para obtener más información.
The DNF Versionlock plugin is useful in blocking unplanned updates to Kubernetes rpms. Occasionally, the Kubernetes version in a Fedora release reaches end-of-life and a new version of Kubernetes is added to the repositories. Or, an upgrade to Fedora on a cluster machine will also result in a different version of Kubernetes. Once DNF Versionlock is installed, the following command will hold kubernetes rpms and the cri-o rpm at the 1.31 major:minor version but still allow patch updates to occur:
$ sudo dnf versionlock add kubernetes*-1.31.* cri-o-1.31.*
Solución de problemas de CrashLoopBackOff
El equipo de CoreDNS proporciona una guía en el siguiente solución de problemas de bucles en clústeres de Kubernetes con varias opciones para ayudar a resolver el problema.
Una opción "rápida y sencilla", como la describe el equipo de CoreDNS, consiste en editar el configmap de CoreDNS usando kubectl. En el configmap, reemplace forward . /etc/resolv.conf con la dirección IP del servidor DNS de su red. Si el servidor DNS tiene la dirección IP 192.168.110.201, el resultado sería forward . 192.168.110.201. Para editar el configmap de CoreDNS, use:
$ kubectl edit configmap coredns -n kube-system
kubectl iniciará el editor para tu instancia de Fedora. El editor predeterminado de Fedora es nano, que se puede cambiar fácilmente.
Otra opción es inhabilitar la resolución del resguardo resuelto por systemd en la máquina que aloja el clúster mediante el código a continuación. Muchas gracias a @jasonbrooks (https://pagure.io/user/jasonbrooks) por su revisión y recomendaciones.
$ sudo mkdir -p /etc/systemd/resolved.conf.d/
$ sudo cat <<EOF | sudo tee /etc/systemd/resolved.conf.d/stub-listener.conf
[Resolve]
DNSStubListener=no
EOF
Want to help? Learn how to contribute to Fedora Docs ›