Parte 1 Implementamos el entorno para trabajar con microservicios. Parte 1 instalando Kubernetes HA en metal desnudo (Debian)
Hola, queridos lectores de Habr!
En una publicación anterior , hablé sobre cómo implementar un clúster de conmutación por error de Kubernetes. Pero el hecho es que en Kubernetes es conveniente implementar aplicaciones sin estado que no necesitan mantener su estado o trabajar con datos. Pero en la mayoría de los casos, necesitamos guardar datos y no perderlos al reiniciar los hogares.
Kubernetes utiliza volúmenes para estos fines. Cuando trabajamos con soluciones en la nube de Kubernetes, no hay problemas particulares. Solo necesitamos pedir el volumen requerido de Google, Amazon u otro proveedor de la nube y, guiados por la documentación , conectar los volúmenes recibidos a los pods.
Cuando tratamos con metal desnudo, las cosas son un poco más complicadas. Hoy quiero hablar sobre una de las soluciones basadas en el uso de ceph.
En esta publicación diré:
- cómo implementar almacenamiento distribuido ceph
- Cómo usar Ceph cuando trabajas con Kubernetes
Introduccion
Para empezar, me gustaría explicar a quién será útil este artículo. En primer lugar, para los lectores que implementaron el clúster de acuerdo con mi primera publicación para continuar creando una arquitectura de microservicio. En segundo lugar, para las personas que desean intentar desplegar un clúster ceph por su cuenta y evaluar su rendimiento.
En esta publicación, no abordaré el tema de la planificación de clústeres para ninguna necesidad, solo hablaré sobre principios y conceptos generales. No profundizaré en la "sintonización" y la sintonización profunda, hay muchas publicaciones sobre este tema, incluso sobre el Habr. El artículo será más introductorio, pero al mismo tiempo le permitirá obtener una solución de trabajo que pueda adaptar a sus necesidades en el futuro.
- Lista de hosts, recursos de host, SO y versiones de software
- Estructura del cúmulo cefálico
- Configurar nodos de clúster antes de la instalación
- Instalar ceph-deploy
- Crear un grupo ceph
- Configuración de red
- Instalar paquetes ceph
- Instalación e inicialización de monitores.
- Agregar OSD
- Conecta ceph a kubernetes
- Crear un grupo de datos
- Crear un secreto de cliente
- Implementar aprovisionador ceph rbd
- Crear una clase de almacenamiento
- Prueba de Kubernetes + ligamento cefálico
- Lista de materiales utilizados en la preparación del artículo.
Lista de hosts y requisitos del sistema
Cuando escribo un artículo, uso máquinas virtuales con esta configuración
Cada uno tiene instalado un sistema operativo Debian 9.5. Estas son máquinas de prueba, cada una con dos discos, el primero para el sistema operativo, el segundo para el cef OSD.
Implementaré el clúster a través de la utilidad ceph-deploy. Puede implementar un clúster ceph en modo manual, todos los pasos se describen en la documentación, pero el propósito de este artículo es decir qué tan rápido puede implementar ceph y comenzar a usarlo en kubernetes.
Ceph es bastante glotón por los recursos, especialmente la RAM. Para una buena velocidad, es recomendable utilizar unidades ssd.
Puede leer más sobre los requisitos en la documentación oficial de ceph.
Estructura del cúmulo cefálico
MON
Un monitor es un demonio que actúa como el coordinador desde el cual comienza el clúster. Tan pronto como tengamos al menos un monitor en funcionamiento, tenemos un clúster Ceph. El monitor almacena información sobre el estado y la condición del clúster intercambiando varias tarjetas con otros monitores. Los clientes recurren a los monitores para averiguar en qué OSD escribir / leer datos. Cuando implementa un nuevo almacenamiento, lo primero que hace es crear un monitor (o varios). El clúster puede vivir en un monitor, pero se recomienda hacer 3 o 5 monitores para evitar la caída de todo el sistema debido a la caída de un solo monitor. Lo principal es que el número de estos debe ser impar para evitar situaciones de cerebro dividido. Los monitores trabajan en un quórum, por lo que si cae más de la mitad de los monitores, el clúster se bloqueará para evitar inconsistencias en los datos.
Mons.
El demonio Ceph Manager funciona con el demonio monitor para proporcionar un control adicional.
Desde la versión 12.x, el demonio ceph-mgr se ha vuelto necesario para el funcionamiento normal.
Si el demonio mgr no se está ejecutando, verá una advertencia al respecto.
OSD (dispositivo de almacenamiento de objetos)
OSD es una unidad de almacenamiento que almacena los datos en sí y procesa las solicitudes de los clientes mediante el intercambio de datos con otros OSD. Esto suele ser un disco. Y generalmente para cada OSD hay un demonio OSD separado que puede ejecutarse en cualquier máquina en la que esté instalado este disco.
Los tres demonios funcionarán en cada máquina de nuestro clúster. En consecuencia, supervise y administre demonios como servicio y demonios OSD para una unidad de nuestra máquina virtual.
Configurar nodos de clúster antes de la instalación
La documentación de ceph especifica el siguiente flujo de trabajo:
Trabajaré desde el primer nodo del clúster ceph01-test, será Admin Node, también contendrá archivos de configuración para la utilidad ceph-deploy. Para que la utilidad ceph-deploy funcione correctamente, todos los nodos del clúster deben ser accesibles a través de ssh con el nodo Admin. Por conveniencia, escribiré los nombres cortos de los hosts para el clúster
10.73.88.52 ceph01-test 10.73.88.53 ceph02-test 10.73.88.54 ceph03-tset
Y copie las claves a los otros hosts. Todos los comandos que ejecutaré desde la raíz.
ssh-copy-id ceph02-test ssh-copy-id ceph03-test
Documentación de configuración
ceph-deployInstalar ceph-deploy
El primer paso es instalar ceph-deploy en la máquina ceph01-test
wget -q -O- 'https://download.ceph.com/keys/release.asc' | apt-key add -
A continuación, debe elegir la versión que desea poner. Pero aquí hay dificultades, actualmente ceph para Debian OS solo admite paquetes luminosos.
Si desea poner una versión más reciente, tendrá que usar un espejo, por ejemplo
https://mirror.croit.io/debian-mimic/dists/
Agregue un repositorio con mímica en los tres nodos
apt install curl apt-transport-https -y curl https://mirror.croit.io/keys/release.gpg > /usr/share/keyrings/croit-signing-key.gpg echo 'deb [signed-by=/usr/share/keyrings/croit-signing-key.gpg] https://mirror.croit.io/debian-mimic/ stretch main' > /etc/apt/sources.list.d/croit-ceph.list apt update apt install ceph-deploy
Si luminoso es suficiente para ti, entonces puedes usar los repositorios oficiales
echo deb https://download.ceph.com/debian-luminous/ $(lsb_release -sc) main | tee /etc/apt/sources.list.d/ceph.list apt-transport-https apt update apt install ceph-deploy
También instalamos NTP en los tres nodos.
ya que esta recomendación está en la documentación del cephRecomendamos instalar NTP en los nodos Ceph (especialmente en los nodos Ceph Monitor) para evitar problemas derivados de la deriva del reloj.
apt install ntp
Asegúrese de habilitar el servicio NTP. Asegúrese de que cada nodo Ceph use el mismo servidor NTP. Puedes ver más detalles aquí
Crear un grupo ceph
Cree un directorio para archivos de configuración y archivos ceph-deploy
mkdir my-cluster cd my-cluster
Creemos una nueva configuración de clúster, al crear, indique que habrá tres monitores en nuestro clúster
ceph-deploy new ceph01-test ceph02-test ceph03-test
Configuración de red
Ahora el punto importante, es hora de hablar sobre la red para ceph. Ceph utiliza dos redes públicas y una red de clúster para trabajar.
Como puede ver en el diagrama de la red pública, este es el nivel de usuario y aplicación, y la red de clúster es la red a través de la cual se replican los datos.
Es altamente deseable separar estas dos redes entre sí. Además, la red de clúster de velocidad de red es deseable al menos 10 Gb.
Por supuesto, puede mantener todo en la misma red. Pero esto está plagado del hecho de que tan pronto como aumenta el volumen de replicación entre los OSD, por ejemplo, cuando los nuevos OSD (discos) caen o se agregan, la carga de la red aumentará MUY. Por lo tanto, la velocidad y la estabilidad de su infraestructura dependerán en gran medida de la red utilizada por ceph.
Desafortunadamente, mi clúster de virtualización no tiene una red separada, y usaré un segmento de red común.
La configuración de red para el clúster se realiza a través del archivo de configuración, que generamos con el comando anterior.
/my-cluster# cat ceph.conf [global] fsid = 2e0d92b0-e803-475e-9060-0871b63b6e7f mon_initial_members = ceph01-test, ceph02-test, ceph03-test mon_host = 10.73.88.52,10.73.88.53,10.73.88.54 auth_cluster_required = cephx auth_service_required = cephx auth_client_required = cephx
Como podemos ver, la implementación de cef no creó la configuración de red predeterminada para nosotros, por lo que agregaré el parámetro public network = {public-network / netmask} a la sección global de la configuración. Mi red es 10.73.0.0/16, así que después de agregar mi configuración se verá así
[global] fsid = 2e0d92b0-e803-475e-9060-0871b63b6e7f mon_initial_members = ceph01-test, ceph02-test, ceph03-test mon_host = 10.73.88.52,10.73.88.53,10.73.88.54 public network = 10.73.0.0/16 auth_cluster_required = cephx auth_service_required = cephx auth_client_required = cephx
Si desea separar la red del clúster del público, agregue el parámetro cluster network = {cluster-network / netmask}
Puede leer más sobre redes en la documentación.
Instalar paquetes ceph
Usando ceph-deploy, instalamos todos los paquetes ceph que necesitamos en nuestros tres nodos.
Para hacer esto, en ceph01-test, ejecute
Si la versión es mímica, entonces
ceph-deploy install --release mimic ceph01-test ceph02-test ceph03-test
Si la versión es luminosa, entonces
ceph-deploy install --release luminous ceph01-test ceph02-test ceph03-test
Y espera hasta que todo esté establecido.
Instalación e inicialización de monitores.
Después de instalar todos los paquetes, crearemos e iniciaremos los monitores de nuestro clúster.
C ceph01-test haz lo siguiente
ceph-deploy mon create-initial
Se crearán monitores en el proceso, se lanzarán demonios y ceph-deploy verificará el quórum.
Ahora dispersa las configuraciones en los nodos del clúster.
ceph-deploy admin ceph01-test ceph02-test ceph03-test
Y verifique el estado de nuestro clúster, si hizo todo correctamente, entonces el estado debería ser
SALUD_OK
~/my-cluster# ceph status cluster: id: 2e0d92b0-e803-475e-9060-0871b63b6e7f health: HEALTH_OK services: mon: 3 daemons, quorum ceph01-test,ceph02-test,ceph03-test mgr: no daemons active osd: 0 osds: 0 up, 0 in data: pools: 0 pools, 0 pgs objects: 0 objects, 0 B usage: 0 B used, 0 B / 0 B avail pgs:
Crear mgr
ceph-deploy mgr create ceph01-test ceph02-test ceph03-test
Y verifica el estado nuevamente
ceph -s
Debería aparecer una línea
mgr: ceph01-test(active), standbys: ceph02-test, ceph03-test
Escribimos la configuración a todos los hosts en el clúster
ceph-deploy admin ceph01-test ceph02-test ceph03-test
Agregar OSD
Por el momento tenemos un clúster en funcionamiento, pero todavía no tiene discos (osd en terminología ceph) para almacenar información.
OSD se puede agregar con el siguiente comando (vista general)
ceph-deploy osd create --data {device} {ceph-node}
En mi banco de pruebas, el disco / dev / sdb se asigna bajo osd, por lo que en mi caso los comandos serán los siguientes
ceph-deploy osd create --data /dev/sdb ceph01-test ceph-deploy osd create --data /dev/sdb ceph02-test ceph-deploy osd create --data /dev/sdb ceph03-test
Verifique que todos los OSD estén funcionando.
ceph -s
Conclusión
cluster: id: 2e0d92b0-e803-475e-9060-0871b63b6e7f health: HEALTH_OK services: mon: 3 daemons, quorum ceph01-test,ceph02-test,ceph03-test mgr: ceph01-test(active) osd: 3 osds: 3 up, 3 in
También puede probar algunos comandos útiles para OSD.
ceph osd df ID CLASS WEIGHT REWEIGHT SIZE USE AVAIL %USE VAR PGS 0 hdd 0.00490 1.00000 5.0 GiB 1.0 GiB 4.0 GiB 20.05 1.00 0 1 hdd 0.00490 1.00000 5.0 GiB 1.0 GiB 4.0 GiB 20.05 1.00 0 2 hdd 0.00490 1.00000 5.0 GiB 1.0 GiB 4.0 GiB 20.05 1.00 0 TOTAL 15 GiB 3.0 GiB 12 GiB 20.05
y
ceph osd tree ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF -1 0.01469 root default -3 0.00490 host ceph01-test 0 hdd 0.00490 osd.0 up 1.00000 1.00000 -5 0.00490 host ceph02-test 1 hdd 0.00490 osd.1 up 1.00000 1.00000 -7 0.00490 host ceph03-test 2 hdd 0.00490 osd.2 up 1.00000 1.00000
Si todo está bien, entonces tenemos un grupo ceph en funcionamiento. En la siguiente parte, diré cómo usar ceph con kubernetes
Conecta ceph a kubernetes
Desafortunadamente, no podré describir en detalle la operación de los volúmenes de Kubernetes en este artículo, así que intentaré encajar en un párrafo.
Kubernetes utiliza clases de almacenamiento para trabajar con volúmenes de datos, cada clase de almacenamiento tiene su propio aprovisionador, puede considerarlo como una especie de "controlador" para trabajar con diferentes volúmenes de almacenamiento de datos. La lista completa que admite kubernetes se puede encontrar en la documentación oficial .
Kubernetes también tiene soporte para trabajar con rbd, pero no hay un cliente rbd instalado en la imagen oficial de kube-controller-manager, por lo que debe usar una imagen diferente.
También debe tenerse en cuenta que los volúmenes (pvc) creados como rbd solo pueden ser ReadWriteOnce (RWO) y, lo que significa que puede montar el volumen creado SOLO en un hogar.
Para que nuestro clúster pueda trabajar con volúmenes ceph, necesitamos:
en un grupo Ceph:
- crear grupo de datos en el grupo ceph
- crear un cliente y clave de acceso al grupo de datos
- obtener secreto administrativo ceph
Para que nuestro clúster pueda trabajar con volúmenes ceph, necesitamos:
en un grupo Ceph:
- crear grupo de datos en el grupo ceph
- crear un cliente y clave de acceso al grupo de datos
- obtener secreto administrativo ceph
en el clúster de Kubernetes:
- crear secreto administrativo ceph y clave de cliente ceph
- instale el aprovisionador ceph rbd o cambie la imagen de kube-controller-manager a una imagen que admita rbd
- crear secreto con clave de cliente ceph
- crear clase de almacenamiento
- instalar ceph-common en las notas de trabajo de kubernetes
Crear un grupo de datos
En el clúster ceph, cree un grupo para los volúmenes de kubernetes
ceph osd pool create kube 8 8
Aquí haré una pequeña explicación, los números 8 8 al final son los números de pg y pgs. Estos valores dependen del tamaño de su grupo ceph. Hay calculadoras especiales que calculan la cantidad de pg y pgs, por ejemplo, oficial de ceph
Para comenzar, recomiendo dejarlo de forma predeterminada, si en el futuro esta cantidad se puede aumentar (solo se puede reducir con la versión Nautilus).
Crear un cliente para un grupo de datos
Crear un cliente para el nuevo grupo
ceph auth add client.kube mon 'allow r' osd 'allow rwx pool=kube'
Recibiremos una clave para el cliente, en el futuro la necesitaremos para crear un secreto kubernetes
ceph auth get-key client.kube AQDd5aldka5KJRAAkpWTQYUMQi+5dfGDqSyxkg==
Obteniendo clave de administrador
Y obtener la clave de administrador
ceph auth get client.admin 2>&1 |grep "key = " |awk '{print $3'} AQAv+Itdx4DwKBAAKVhWRS3+eEPqV3Xrnlg9KA==
En el grupo ceph, todo el trabajo se ha completado y ahora tenemos que ir a una máquina que tenga acceso al grupo kubernetes
Trabajaré con la prueba master01 (10.73.71.25) del clúster implementado por mí en la primera publicación.
Crear un secreto de cliente
Cree un archivo con el token del cliente que recibimos (no olvide reemplazarlo con su token)
echo AQDd5aldka5KJRAAkpWTQYUMQi+5dfGDqSyxkg== > /tmp/key.client
Y crea un secreto que usaremos en el futuro
kubectl create secret generic ceph-secret --from-file=/tmp/key.client --namespace=kube-system --type=kubernetes.io/rbd
Crear secreto de administrador
Cree un archivo con token de administrador (no olvide reemplazarlo con su token)
echo AQAv+Itdx4DwKBAAKVhWRS3+eEPqV3Xrnlg9KA== > /tmp/key.admin
Después de eso, crea un secreto de administrador
kubectl create secret generic ceph-admin-secret --from-file=/tmp/key.admin --namespace=kube-system --type=kubernetes.io/rbd
Comprueba que se han creado secretos
kubectl get secret -n kube-system | grep ceph ceph-admin-secret kubernetes.io/rbd 1 8m31s ceph-secret kubernetes.io/rbd 1 7m32s
Primero, el método implementa ceph rbd provisioner
Clonamos el repositorio kubernetes-incubator / external-storage de github, tiene todo lo que necesitas para hacer que los kubernetes se agrupen con el repositorio ceph.
git clone https://github.com/kubernetes-incubator/external-storage.git cd external-storage/ceph/rbd/deploy/ NAMESPACE=kube-system sed -r -i "s/namespace: [^ ]+/namespace: $NAMESPACE/g" ./rbac/clusterrolebinding.yaml ./rbac/rolebinding.yaml
kubectl -n $NAMESPACE apply -f ./rbac
Conclusión
clusterrole.rbac.authorization.k8s.io/rbd-provisioner created clusterrolebinding.rbac.authorization.k8s.io/rbd-provisioner created deployment.extensions/rbd-provisioner created role.rbac.authorization.k8s.io/rbd-provisioner created rolebinding.rbac.authorization.k8s.io/rbd-provisioner created serviceaccount/rbd-provisioner created
Método dos: Reemplace la imagen de kube-controller-manager
No hay soporte de rbd en la imagen oficial de kube-controller-manager, por lo que tendremos que cambiar la imagen del controlador-manager.
Para esto, en cada uno de los asistentes de Kubernetes, debe editar el archivo kube-controller-manager.yaml y reemplazar la imagen con gcr.io/google_containers/hyperkube:v1.15.2. Preste atención a la versión de la imagen que debe coincidir con su versión del clúster de Kubernetes.
vim /etc/kubernetes/manifests/kube-controller-manager.yaml
Después de eso, deberá reiniciar kube-controller-manager
ubectl get pods -A | grep manager kube-system kube-controller-manager-master01-test 1/1 Running 0 5m54s kube-system kube-controller-manager-master02-test 1/1 Running 0 5m54s kube-system kube-controller-manager-master03-test 1/1 Running 9111 103d
Los pods deben actualizarse automáticamente, pero si por alguna razón esto no sucedió, puede volver a crearlos manualmente, mediante la eliminación.
kubectl delete pod -n kube-system kube-controller-manager-master01-test kubectl delete pod -n kube-system kube-controller-manager-master02-test kubectl delete pod -n kube-system kube-controller-manager-master03-test
Comprueba que todo está bien
kubectl describe pod -n kube-system kube-controller-manager-master02-test | grep Image: Image: gcr.io/google_containers/hyperkube:v1.15.2
-
Crear una clase de almacenamiento
Método uno: si utilizó el aprovisionador ceph.com/rbd
Cree un archivo yaml con una descripción de nuestra clase de almacenamiento. Además, todos los archivos utilizados a continuación se pueden descargar en mi repositorio en el directorio ceph
cat <<EOF >./storage-class.yaml kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: ceph-rbd provisioner: ceph.com/rbd parameters: monitors: 10.73.88.52:6789, 10.73.88.53:6789, 10.73.88.54:6789 pool: kube adminId: admin adminSecretNamespace: kube-system adminSecretName: ceph-admin-secret userId: kube userSecretNamespace: kube-system userSecretName: ceph-secret imageFormat: "2" imageFeatures: layering EOF
E incrustarlo en nuestro grupo
kubectl apply -f storage-class.yaml
Comprueba que todo está bien
kubectl get sc NAME PROVISIONER AGE ceph-rbd ceph.com/rbd 7s
Método dos: si utilizó el aprovisionador kubernetes.io/rbd
Crear clase de almacenamiento
cat <<EOF >./storage-class-hyperkube.yaml kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: ceph-rbd provisioner: kubernetes.io/rbd allowVolumeExpansion: true parameters: monitors: 10.73.88.52:6789, 10.73.88.53:6789, 10.73.88.54:6789 pool: kube adminId: admin adminSecretNamespace: kube-system adminSecretName: ceph-admin-secret userId: kube userSecretNamespace: kube-system userSecretName: ceph-secret imageFormat: "2" imageFeatures: layering EOF
E incrustarlo en nuestro grupo
kubectl apply -f storage-class-hyperkube.yaml storageclass.storage.k8s.io/ceph-rbd created
Comprueba que todo está bien
kubectl get sc NAME PROVISIONER AGE ceph-rbd kubernetes.io/rbd 107s
Prueba de Kubernetes + ligamento cefálico
Antes de probar ceph + kubernetes, debe instalar el paquete ceph-common en CADA código de trabajo del clúster.
apt install curl apt-transport-https -y curl https://mirror.croit.io/keys/release.gpg > /usr/share/keyrings/croit-signing-key.gpg echo 'deb [signed-by=/usr/share/keyrings/croit-signing-key.gpg] https://mirror.croit.io/debian-mimic/ stretch main' > /etc/apt/sources.list.d/croit-ceph.list apt update apt install ceph-common
Crear un archivo yaml PersistentVolumeClaim
cat <<EOF >./claim.yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: claim1 spec: accessModes: - ReadWriteOnce storageClassName: ceph-rbd resources: requests: storage: 1Gi EOF
Matarlo
kubectl apply -f claim.yaml
Verifique que se cree PersistentVolumeClaim.
bectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE claim1 Bound pvc-d1e47825-289c-4201-acb8-033e62a3fe81 1Gi RWO ceph-rbd 44m
Y también creó automáticamente PersistentVolume.
kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-d1e47825-289c-4201-acb8-033e62a3fe81 1Gi RWO Delete Bound default/claim1 ceph-rbd 37m
Creemos un pod de prueba en el que incluyamos el pvc creado en el directorio / mnt. Ejecute este archivo /mnt/test.txt con el texto "¡Hola mundo!"
cat <<EOF >./create-file-pod.yaml kind: Pod apiVersion: v1 metadata: name: create-file-pod spec: containers: - name: test-pod image: gcr.io/google_containers/busybox:1.24 command: - "/bin/sh" args: - "-c" - "echo Hello world! > /mnt/test.txt && exit 0 || exit 1" volumeMounts: - name: pvc mountPath: "/mnt" restartPolicy: "Never" volumes: - name: pvc persistentVolumeClaim: claimName: claim1 EOF
Lo mataremos y verificaremos que ha completado su tarea.
kubectl apply -f create-file-pod.yaml kubectl get pods -w
Esperemos el estado
create-file-pod 0/1 Completed 0 16s
Creemos otro, conectemos nuestro volumen pero ya en / mnt / test, y luego asegúrese de que el archivo creado por el primer volumen esté en su lugar.
cat <<EOF >./test-pod.yaml kind: Pod apiVersion: v1 metadata: name: test-pod spec: containers: - name: test-pod image: gcr.io/google_containers/busybox:1.24 command: - "/bin/sh" args: - "-c" - "sleep 600" volumeMounts: - name: pvc mountPath: "/mnt/test" restartPolicy: "Never" volumes: - name: pvc persistentVolumeClaim: claimName: claim1 EOF
Ejecute kubectl get po -w y espere hasta que el pod se esté ejecutando
Después de eso, veamos y verifiquemos que el volumen esté conectado y nuestro archivo en el directorio / mnt / test
kubectl exec test-pod -ti sh cat /mnt/test/test.txt Helo world!
Gracias por leer hasta el final. Perdón por el retraso en la publicación.
Estoy listo para responder todas las preguntas en mensajes personales o en las redes sociales que se indican en mi perfil.
En la próxima publicación pequeña, le diré cómo implementar el almacenamiento S3 basado en el clúster ceph creado, y luego de acuerdo con el plan de la primera publicación.
Materiales utilizados para publicación