Uso de OpenStack como proveedor de infraestructura en Rancher

Resumen

Rancher es un proyecto open-source que nos permite administrar clusters de Kubernetes. Su gran ventaja es que permite gestionar desde un único lugar clusters Kubernetes alojados bien en alguno de los proveedores de Kubernetes más populares, como Google Container Engine, Amazon EKS o Azure Kubernetes Service, o bien, en proveedores de infraestructura, como Amazon EC2, Microsoft Azure, Digital Ocean, RackSpace, OpenStack, SoftLayer, vSphere, entre otros.

En este tutorial veremos por un lado, cómo crear un cluster Kubernetes usando OpenStack como proveedor de infaestructura para el máster y los nodos worker. Por otro lado, veremos cómo usar OpenStack Cinder para propocionar almacenamiento persistente a clusters Kubernetes creados sobre OpenStack.

1. Instalación y configuración inicial de Rancher

Rancher es una plataforma de gestión de distribuciones de Kubernetes en proveedores diferentes (Google, Amazon, Microsoft, RackSpace, OpenStack, vSphere, …). Rancher permite la creación y administración centralizada de clusters de Kubernetes independientemente del proveedor elegido. Además, permite usar catálogos de aplicaciones a partir de repositorios de charts Helm para desplegarlas de forma sencilla.

A continuación veremos cómo realizar una instalación básica de Rancher y cómo configurarlo para que Rancher pueda crear clusters de Kubernetes usando OpenStack como IaaS.

1.1. Instalación de Rancher

Siguiendo la Guía rápida de instalación de Rancher, a partir de una máquina Ubuntu configurada con Docker ejecutaremos

sudo docker run -d \
    --volumes-from rancher-data \ (1)
    --restart=unless-stopped \
    -p 80:80 -p 443:443 \
    rancher/rancher:latest`

1	Almacenamos los datos de Rancher como un volumen fuera del contenedor.

Instalación de Rancher usando certificados SSL

Si disponemos de certificados SSL podemos iniciar Rancher indicándole que use los certificados. En el caso de Rancher-STIC, hemos colocado los certificados en un directorio que pasamos como volumen a Rancher.

docker run -d \
    --restart=unless-stopped \
    -p 80:80 -p 443:443 \
    -v /home/ubuntu/rancherdata:/var/lib/rancher \ (1)
    -v /home/ubuntu/certificados/star_stic_ual_es.crt:/etc/rancher/ssl/cert.pem \ (2)
    -v /home/ubuntu/certificados/star_stic_ual_es.key:/etc/rancher/ssl/key.pem \ (3)
    -v /home/ubuntu/certificados/DigiCertCA.crt:/etc/rancher/ssl/cacerts.pem \ (4)
    rancher/rancher:latest

1	Volumen para almacenamiento de datos
2	Concatenación del certificado de Rancher con el de la entidad certificadora (Rancher usa cadenas de certificados)
3	Clave privada
4	Entiidad certificadora

Si no se va a usar la entidad certificadora, usar este script

docker run -d \
    --restart=unless-stopped \
    -p 80:80 -p 443:443 \
    -v /home/ubuntu/rancherdata:/var/lib/rancher \ (1)
    -v /home/ubuntu/certificados/star_stic_ual_es.crt:/etc/rancher/ssl/cert.pem \ (2)
    -v /home/ubuntu/certificados/star_stic_ual_es.key:/etc/rancher/ssl/key.pem \ (3)
    rancher/rancher:latest \
    --no-cacerts (4)

1	Volumen para almacenamiento de datos
2	Concatenación del certificado de Rancher con el de la entidad certificadora (Rancher usa cadenas de certificados)
3	Clave privada
4	Desactivación de los certificados predeterminados generados por Rancher

2. Activación de OpenStack como proveedor de infraestructura de cómputo para Rancher

De forma predeterminada, Rancher ofrece los siguientes proveedores para la creación de clusters Kubernetes:

Proveedores de Kubernetes: Google Container Engine, Amazon EKS y Azure Kubernetes Service
Proveedores de infraestructura: Amazon EC2, Microsoft Azure, Digital Ocean, y vSphere.

Sin embargo, otros proveedores de infraestructura como RackSpace, OpenStack, SoftLayer, entre otros, no están disponibles de forma predeterminada.

Para activar OpenStack como nuevo proveedor de infraestructura (esto es aplicable a cualquier otro proveedor, p.e. RackSpace), seleccionaremos Global como cluster y a continuación Node Drivers en la barra de menú. Esta acción muestra todos los proveedores que podemos añadir para la creación de los nodos de los clusters Kubernetes que creemos.

La figura siguiente ilustra la lista de proveedores y cómo se activa OpenStack como proveedor de infraestructura.

Al pulsar Activate sobre OpenStack quedará activado OpenStack como proveedor de infraestructura, tal y como ilustra la figura siguiente:

Sin embago, esto no es suficiente. A continuación, hay que definir la plantilla con la que se crearán en OpenStack los nodos del cluster Kubernetes (master y workers)

2.1. Creación de la plantilla para nodos

Google Container Engine, Amazon EKS y demás, son productos comerciales que ya tienen establecida su URL, los nombres de las zonas de disponibilidad, los nombres de las imágenes para la creación de nodos, y demás. Sin embargo, dado que no existe un único proveedor OpenStack, los parámetros citados anteriormente como URL, nombres de zonas de disponibilidad, nombres de imagen, y demás, pueden variar (y seguro que lo hacen) de un proveedor OpenStack a otro.

Cada usuario de Rancher tendrá que configurar sus propias plantillas para especificar los distintos proveedores OpenStack a los que tenga acceso, así como las distintas configuraciones de instancia en OpenStack que quiere usar en función del tipo de nodo Kubernetes que vaya a crear.

Para crear una plantilla, en el menú desplegable del usuario seleccionamos Node Templates y después pulsamos el botón Add Template.

Esto abrirá un cuadro de diálogo como el de la figura siguiente, en el que tendremos que indicar los parámetros de la plataforma OpenStack a la que le vamos a solicitar los recursos, así como los parámetros de la instancia para la plantilla que estamos creando (como nombre imagen, sabor, red y demás)

A continuación se muestran los parámetros a introducir en este cuadro de diálogo

activeTimeout: Dejar el valor predeterminado de 200, que será el timeout que permitimos a OpenStack para la creación de nodos.
authURL: Endpoint público de Keystone que proporciona la auntenticación. En nuestro caso http://openstack.stic.ual.es:5000/v3 (sólo accesible desde la VPN de la UAL). Esta información la puede encontrar el administrador de OpenStack abriendo la consola de Horizon y consultando los servicios en el menu Admin | System Information. También se puede obtener la URL mediante el CLI de OpenStack con:

openstack endpoint list

availabilityZone: Zona de disponibilidad donde se crearán las instancias para los nodos Kubernetes que se creen con esta plantilla. En nuestro caso introduciremos nova.
domainName: Nombre del dominio al que pertenece el usuario que proporciona los recursos OpenStack a esta plantilla. En nuestro caso introduciremos default. En lugar de configurar el parámetro domainId, se podría configurar el parámetro domainId, pero esto es un valor más difícil de obtener.
endPointType: Tipo de endpoint que usaremos para interactuar con el componente Keystone de OpenStack para la autenticación. Nosotros dejaremos publicURL, ya que Rancher no tiene acceso a la red de túnel ni a la de mantenimiento de OpenStack.
flavorName: Nombre completo del sabor con el que se crearán los nodos que se creen con esta plantilla. En este ejemplo usaremos large, aunque podemos elegir cualquier otro entre los disponibles en el OpenStack al que estemos accediendo (p.e. tiny, small, large, xlarge, y demás).
floatingipPool: Nombre de la red externa que proporciona las IP flotantes a las instancias creadas. En nuestro caso introduciremos ual-net.
imageName: Nombre completo de la imagen a usar para crear las instancias. En nuestro caso usaremos Ubuntu 18.04 LTS, aunque podríamos haber usado cualquiera de las disponibles en OpenStack-STIC (CentOS 7, Debian10, openSUSE Leap 15.1, …).
ipVersion: Dejamos 4, ya que las direcciones que usamos son IPv4.
keypairName: Nombre del archivo de clave pública que se inyectará a la instancia en la creación, y que por tanto, deberá estar disponible con ese nombre en el proyecto OpenStack en el que se van a crear las instancias que se creen usando esta plantilla. (p.e. os-sistemas)
netName: Nombre de la red a la que se conectarán las instancias que se creen de acuerdo con esta plantilla. Revisa las redes de tu proyecto OpenStack e identifica el nombre de la red donde se sitúarán las instancias a crear (p.e. k8s-net).
password: Contraseña del usuario en OpenStack para poder dar acceso a Rancher para que cree las instancias.
privateKeyFile: Contenido de la clave privada que usará Rancher para aprovisionar las instancias y que será la pareja de la clave pública que se ha introducido en keypairName.
region: Nombre de la región. En nuestro caso es RegionOne
secGroups: Lista de grupos de seguridad del proyecto OpenStack separadas por comas aplicables a las instancias creadas con esta plantilla (p.e. default)
sshPort: Puerto de acceso a las instancias. Dejamos el valor 22.
sshUser: Nombre de usuario de la instancia que se va a crear, y que dependerá del tipo e imagen usada para crear la instancia. Por ejemplo, para las imágenes Ubuntu el usuario es ubuntu, para las Debian es debian, para las Fedora es fedora.
tenantName: Nombre del proyecto OpenStack en el que se crearán las instancias que usen esta plantilla. Revisa el nombre del proyecto en Horizon para obtener este valor.
userName: Nombre de usuario OpenStack que usará esta plantilla.

Finalmente, asignamos un nombre a esta plantilla (p.e. ` Ubuntu 18.04 LTS large`)

A partir de este momento ya tenemos una plantilla con la que podremos crear los nodos de nuestro cluster Kubernetes. Todos los nodos que se creen usando esta plantilla tendrán las características definidas en la plantilla (imagen, sabor, red, grupos de seguridad, y demás).

Creacion de varias plantillas

Para ajustar mejor la necesidad de cada tipo de nodo a crear se pueden definir plantillas diferentes con sabores diferentes con mayor o menor cantidad de recursos.

Para crear una segunda plantilla a partir de la primera, podemos clonar la plantilla anterior (con la opción clone que ofrece Rancher y hacerle unos ajustes para ampliar por ejemplo el flavor de los nodos que tengan la función worker en el cluster de Kubernetes).

La figura siguiente ilustra dos plantillas disponibles para la creación de un cluster Kubernetes, una plantilla con sabor medium para los nodos etcd y Control Plane, y otra plantilla con sabor xlarge para los nodos Worker.

2.2. Creación de cluster Kubernetes usando plantillas

A partir de las plantillas creadas desplegaremos un cluster Kubernetes de ejemplo para tareas de CI. Las caracterísitcas de los nodos son las siguientes:

Un node pool de 3 nodos medium para etcd y Control Plane con prefijo k8-prod-ci.
Un node pool de 4 nodos xlarge para Worker con prefijo k8-prod-ci-worker.

Transcurridos unos minutos, el cluster estará creado y podremos ver en el proyecto OpenStack asociado las instancias creadas distinguidas con los prefijos k8s-prod-ci y k8-prod-ci-worker.

3. Configuración de OpenStack como proveedor de volúmenes

Cinder es el componente de OpenStack que proporciona almacenamiento de bloques. Podemos usar Cinder para la creación de almacenamiento persistente en proyectos Kubernetes. Aquí veremos cómo realizar esta configuración en Rancher.

Para activar OpenStack como proveedor cloud en Rancher hay que configurar una serie de parámetros a través de un archivo de configuración en YAML para las opciones del cluster.

La configuración en Rancher de un proveedor cloud para almacenamiento o cualquier otro servicio (p.e. balanceadores de carga) se realiza a nivel de cluster. Por tanto, habrá que realizar esta configuración en cada cluster Kubernetes.

A la hora de crear el cluster, una vez definida la configuración de los nodos Master y Worker del cluster Kubernetes, configuraremos la parte relacionada con el almacenamiento en volúmenes con Cinder. Para realizar esta configuración seleccionaremos el enlace Edit as YAML. Esto abrirá un cuadro donde configuraremos las opciones de OpenStack y de Cinder para que se puedan proporcionar volúmenes Cinder a este cluster.

También es posible aplicar la configuración de OpenStack como proveedor cloud sobre clusters Kubernetes existentes. Una vez realizados los cambios Rancher reconfigurará el cluster Kubernetes para que se pueda usar Cinder como proveedor de almacenamiento.

3.1. Valores de configuración del archivo YAML

A continuación se muestra el fragmento con la configuración de Cinder como proveedor de almacenamiento de bloques en el cluster. Enlace de descarga de valores de configuración

Las opciones de configuración están agrupadas en varias secciones. Las más importantes para la definición de volúmenes Cinder en Rancher son las secciones global y block_storage de la sección openstackCloudProvider. No obstante, en esta misma sección también hay otras secciones interesantes para otras situaciones específicas (p.e. la sección load_balancer para el uso de balanceadores de carga OpenStack Enlace de descarga de valores de configuración completos incluyendo balanceadores de carga).

  cloud_provider:
    name: openstack
    openstackCloudProvider:
      block_storage: (1)
        ignore-volume-az: true
        trust-device-path: false
      global:
        auth-url: 'http://openstack.stic.ual.es:5000/v3/' (2)
        domain-name: default (3)
        tenant-id: "your-tenant-id-here" (4)
        username: "your-username-here" (5)
        password: "your-password-here" (6)
      load_balancer:
        create-monitor: false
        floating-network-id: "your-external-net-id-here" (7)
        manage-security-groups: false
        monitor-max-retries: 0
        subnet-id: "your-subnet-id-here" (8)
        use-octavia: false
      metadata:
        request-timeout: 0
      route: {}

1	Opciones de configuración de Cinder
2	Endpoint de autenticación de OpenStack-STIC
3	Nombre de dominio usado en OpenStack-STIC
4	ID del proyecto. No se admite el nombre del proyecto. Ver a continuación información sobre Obtención del ID del proyecto
5	Nombre de usuario
6	Contraseña
7	ID de la red externa que proporciona las IPs flotantes
8	ID de la subred del proyecto

Obtención del datos de configuración

El ID del proyecto lo obtenemos mediante la opción de Ver credenciales que está disponible en el menú de OpenStack Project | Compute | API Access. A continuación pulsar el botón View credentials

Aparecerá el cuadro de diálogo User Credentials Details en el que se mostrará el Project ID, que es la información que necesitábamos para completar el YAML de configuración del cluster para uso de Cinder.
floating-network-id lo obtendremos en el menú Network | Networks, seleccionando la red externa (ual-net). En la pestaña Overview aparecerán los datos necesarios en ID.
El identificador de la subred lo obtendremos en el menú Network | Networks, seleccionando la red del proyecto, después su subred y los datos necesarios están en ID.

4. Creación de volúmenes Cinder en clusters Kubernetes

Los contenedores pueden almacenar datos, pero los datos se pierden al eliminar los contenedores. Kubernetes ofrece volúmenes persistentes, que es almacenamiento externo al pod, ya sea en el host, en un cluster de almacenamiento o almacenamiento cloud. Si un contenedor falla, el contenedor que lo reemplace puede volver a acceder a los datos sin que se produzca pérdida de datos.

Kubernetes ofrece dos formas de almacenamiento persistente: Volúmenes persistentes (Persistent Volumes, PV) y Clases de almacenamiento (Storage classes).

Los volúmenes persitentes (PV):
- Son volúmenes preaprovisionados que se pueden conectar más adelante a los pods.
- Cuando se inicia la aplicación, crea una petición de volumen persistente (Persistent Volume Claim, PVC) y queda ligada al volumen persistente.
- En Rancher se crean a nivel de cluster, no a nivel de proyecto.
Las clases de almacenamiento:
- Representan algo así como drivers de almacenamiento (podríamos tener clases para Cinder, iSCSI, GlusterFS, NFS, …). Más información sobre tipos de volúmenes en Kubernetes.
- Provisionan volúmenes persistentes bajo demanda.
- Permiten crear la PVC directamente sin tener que crear primero el volumen persistente.
- Van creando volúmenes (Cinder) que después son conectados a las PVC.

4.1. Creación de una clase de almacenamiento para Cinder

Si queremos crear volúmenes Cinder, una vez configurado el cluster para usar Cinder como proveedor de almacenamiento, tenemos que crear una clase de almacenamiento.

Para crear una clase de almacenamiento para Cinder:

Seleccionar el cluster a nivel global, no a nivel de proyecto (p.e. Default, System, …).
Seleccionar Storage Classes en el menú Storage
Seleccionar Add Class para añadir una clase de almacenamiento
Introducir un nombre (p.e Cinder) y elegir OpenStack Cinder Volume como proveedor de almacenamiento. (En la sección Customize se puede configurar que se elimine o mantengan los volúmenes asociados tras eliminar un workload)

La selección de OpenStack Cinder Volume como proveedor de almacenamiento tomará los valores configurados en el YAML del cluster de la sección Configuración de OpenStack como proveedor de volúmenes.

4.2. Creación de un volumen persistente

Seleccionar el cluster a nivel global, no a nivel de proyecto (Default, System, …).
En el menú Storage seleccionar Persistent Volumes y pulsar el botón Add Volume.
Introducir los valores un nombre (p.e. myPV), elegir OpenStack Cinder Volume en Volume Plugin, una capacidad (p.e. 10 GB). En la sección Plugin configuration introducir valores para Volume ID, Secret Name y Secret Namespace.
En la sección Customize desplegar Assign to Storage Class y seleccionar la clase cinder creada anteriormente.

El volumen persistente creado aparecerá en la lista y observaremos como no aún no tiene ninguna petición de volumen persistente (Persistent Volume Claim, PVC), por lo que aún no se ha creado ningún volumen en Cinder.

4.3. Creación de una petición de volumen persistente

En Kubernetes se puede crear una petición de volumen persistente (Persistent Volume Claim, PVC) bien a partir de un volumen persitente o a partir de una clase de almacenamiento. Una PVC sí proporciona almacenamiento real para nuestro cluster y si usamos Cinder, veremos los volúmenes creados en OpenStack.

Comencemos creando una PVC. Para ello, seleccionamos el proyecto Default de nuestro cluster y seleccionamos el menú Workloads. A continuación seleccionamos el menú Volumes y pulsamos Add Volume.

A continuación tendremos que indicar si crear la PVC a partir de un volumen persistente previamente creado (p.e. mypv) o bien crear la PVC a partir de una de las clases de almacenamento diponibles (p.e. la clase cinder). Veamos cómo hacer las dos opciones:

Creación de la PVC a partir de un volumen persistente: Introducir un nombre (p.e. pvc-from-persistent-volume), seleccionar el botón de opción Use an existing persistent volume en la sección Source y elegir el volumen persistente en el desplegable Persistent Volume (p.e. mypv).

Esta acción tomará la configuración almacenada en el volumen persistente, que en el caso de mypv es un volumen de 10 GB. Este volumen aparecerá reservado en Cinder en el momento que lo use una aplicación.
Creación de la PVC a partir de una clase de almacenamiento: Introducir un nombre (p.e. pvc-from-storage-class), seleccionar el botón de opción Use a Storage Class to provision a new persistent volume en la sección Source y elegir cinder en el desplegable Storage Class. Esta acción creará en OpenStack un volumen del tamaño especificado y con un nombre aleatorio que se corresponde con el de la PVC

A continuación se muestra el volumen creado.

El volumen creado en OpenStack coincide con la PVC creada desde Rancher. En nuestro caso, la PVC es kubernetes-dynamic-pvc-7c9ebbab-aa63-11e9-b090-fa163ee64fe0

Creación de aplicaciones basadas en volúmenes

El catálogo de aplicaciones de Rancher es bastante amplio. Muchas de las aplicaciones del catálogo permiten la creación de volúmenes. Por ejemplo, podemos crear un MySQL con un volumen asociado de 8 GB, tal y como muestra la figura

Así, de forma predeterminada tendremos un MySQL corriendo en un único pod. Una vez creado, si iniciamos sesión en MySQL, creamos una base de datos de ejemplo y eliminamos el pod, los datos no se perderán. Los datos están almacenados en una PVC, que está almacenada en un volumen Cinder en OpenStack. Si se vuelve a crear un pod que reemplace al pod eliminado, tras iniciar sesión en el nuevo pod se podrá comprobar que se tiene acceso a los mismos datos que tenía el pod eliminado.

4.4. Creación de una petición de volumen mediante manifiesto YAML

Tanto la clase de almacenamiento, como las peticiones de volumen se pueden hacer desde la consola de Rancher o desplegando directamente manifiestos YAML.

A continuación se muestra el manifiesto YAML para la creación de una clase de almacenamiento denominada cinder para OpenStack Cinder

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: cinder
provisioner: kubernetes.io/cinder
parameters:
  availability: nova

La crearemos con kubectl apply -f https://gist.githubusercontent.com/ualmtorres/c4a179accb12cf04a6af5fdc8f438f11/raw/bc274085607900f5335df8d5a2b5915e85b128f5/cinder-sc.yaml.

Consulta los proveedores de almacenamiento de Kubernetes en la documentación oficial.

Una vez creada la clase de almacenamiento, podremos crear peticiones de volumen sobre ella. A continuación se muestra un manifiesto YAML para la creación de una PVC de 9GB sobre la clase de almacenamiento cinder definida anteriormente.

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: cinder-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 9Gi # pass here the size of the volume
  storageClassName: cinder

La crearemos con kubectl apply -f https://gist.githubusercontent.com/ualmtorres/788d6d7803cb32834c4afb96eeef6e5d/raw/dcf488634eac1bdbf0d4933e3eb2def55c8d8925/cinder-pvc.yaml.

Tras crearla, el volumen aparecerá en el menú Storage | Persisten Volumes de Rancher y en la zona de volúmenes de OpenStack (Volumes | Volumes).

5. Creación de volúmenes NFS con Openstack Manila en clusters Kubernetes

Kubernetes permite montar shares NFS existentes. Los volúmenes NFS son volúmenes externos al cluster Kubernetes y son persistentes, de forma que su contenido se mantiene después de la eliminación de los pods que lo tengan montado.

Para este ejemplo usaremos Openstack Manila como servidor NFS. Para los ejemplos ya tenemos creado un share, disponible en en la ruta /var/lib/manila/mnt/share-c3e6b450-9e7b-4144-a113-84cbcd50ddd6 del servidor 192.168.128.17. Dicho share ya tiene configuradas las reglas de acceso de forma que pueda ser montado.

5.1. Creación de un volumen persistente

Seleccionar el cluster a nivel global, no a nivel de proyecto (Default, System, …).
En el menú Storage seleccionar Persistent Volumes y pulsar el botón Add Volume.
Introducir los valores un nombre (p.e. my-share-pv), elegir NFS Share en Volume Plugin, una capacidad (p.e. 10 GB). En la sección Plugin Configuration introducir los valores del path y del server que ha proporcionado OpenStack Manila para el share creado.

A partir desde volumen persistente, podríamos crear volume claims sobre él desde la opción Default del cluster en Resources | Volumes | Add Volume y seleccionando Use an existing persistent volume en Source.

5.2. Creación de una petición de volumen mediante manifiesto YAML

Tanto los volúmnes persistentes como las peticiones de volumen se pueden hacer desde la consola de Rancher o desplegando directamente manifiestos YAML.

A continuación se muestra el manifiesto YAML para la creación de un volumen persistente NFS para un share de OpenStack Manila

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Recycle
  nfs:
    path: /var/lib/manila/mnt/share-c3e6b450-9e7b-4144-a113-84cbcd50ddd6
    server: 192.168.128.17

Lo crearemos con kubectl apply -f https://gist.githubusercontent.com/ualmtorres/3fe119adcacf269442da0d0db9adcc3d/raw/1e54dd73a00bd55f70dd229fab1123c2a5d89787/nfs-pv.yaml

Una vez creado el volumen persistente, podremos crear peticiones de volumen sobre él. A continuación se muestra un manifiesto YAML para la creación de una PVC de 10GB sobre el volumen nfs-pv definido anteriormente.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  storageClassName: ""
  volumeName: nfs-pv

La crearemos con kubectl apply -f https://gist.githubusercontent.com/ualmtorres/4adbc23ae9237197be32d622bad8876c/raw/3403e9da298c971d739575e0aab8f221e99158e3/nfs-pvc.yaml

6. Conclusiones

Rancher ofrece una plataforma integrada para creación y mantenimiento de clusters Kubernetes. En el caso de que usemos proveedores públicos (Google, Azure, Amazon, …) para el despliegue de la infraestructura, basta con completar los parámetros que proporcione el proveedor. Sin embargo, dado que cada cloud OpenStack al que tengamos acceso puede tener parámetros de configuración diferentes (p.e. nombre de las imágenes, sabores, red externa, y demás), debemos configurar nuestras propias plantillas de acuerdo con la instalación de OpenStack a la que tengamos acceso.

En este tutorial hemos visto cómo crear estas plantillas y cómo personalizar la configuración mediante YAML para almacenamiento y balanceadores de carga OpenStack. También hemos visto cómo crear almacenamiento persistente para clusters Kubernetes usando OpenStack Cinder y OpenStack Manila como proveedores de almacenamiento.