En esta ocasión vamos a probar como de bueno o malo es el provider de Terraform para Kubernetes. Por si no lo conoces, Terraform es el "anillo único" que permite gestionar como código todas las infraestructuras que se te pongan por delante (y para las que haya un provider). Una ventaja de Terraform es que si eliminas un objeto de tu código, también se elimina en tu infraestructura, lo que no pasa con Cloudformation de AWS o Heat de OpenStack.

Buscando el Ingress

Con un rápido vistazo a la página del provider de Terraform para Kubernetes echamos en falta algo tan normal como el objeto Ingress y tampoco podemos crear objetos custom. Si además conoces OpenShift verás que faltan DeploymentConfig y Route.

Pero vamos a ver porqué no están los Ingress. Lo primero que pensé es que a lo mejor era un custom que no formaba parte del core de Kubernetes y por eso no estaba agregado así que me fui al código del provider de Kubernetes.
Vi que importaba un tal k8s.io/api/apps/v1 y me fui a buscarlo a github donde vi que el Ingress está implementado en el core directamente ¡desde hace 2 años!

Conclusión: en Terraform faltan cosas que no te esperas que falten, como Ingress aunque parece que algo se está moviendo, y OpenShift viene con muchos objetos que ni se pueden gestionar desde Terraform ni creo que se vayan a poder gestionar a corto plazo aunque algo se está moviendo también.

Caso OpenShift

Si estamos dispuestos a usar Deployments en OpenShift y gestionar las rutas a mano, entonces este provider si nos puede valer.

Con OpenShift he probado esto:

provider "kubernetes" {
  host = "https://openshift.serenity.es:9443"
}

resource "kubernetes_config_map" "example" {
  metadata {
    name = "my-config"
    namespace = "terraform"
  }

  data {
    api_host = "myhost:443"
    db_host  = "dbhost:5432"
  }
}

Y me ha creado el configmap:

jmferrerm@serenity:~/gitops/openshift$ oc get cm
NAME        DATA      AGE
my-config   2         6s

Luego he probado a borrarlo del fichero y lo ha borrado de OpenShift así que en principio hace lo que dice que hace:

jmferrerm@serenity:~/gitops/openshift$ terraform apply
kubernetes_config_map.example: Refreshing state... (ID: terraform/my-config)

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  - destroy

Terraform will perform the following actions:

  - kubernetes_config_map.example


Plan: 0 to add, 0 to change, 1 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

kubernetes_config_map.example: Destroying... (ID: terraform/my-config)
kubernetes_config_map.example: Destruction complete after 0s

Apply complete! Resources: 0 added, 0 changed, 1 destroyed.
jmferrerm@serenity:~/gitops/openshift$ oc get cm
No resources found.

¿Lo uso o no lo uso?

Esto es algo que te toca a ti valorar ... pero si quieres mi opinión, para Kubernetes es un SI rotundo gestionando con un "kubectl apply" los ingress, que raramente van a cambiar, y esperando a que finalmente se cree esa función.

En OpenShift tenemos que estar dispuestos a usar Deployments en vez de DeploymentConfigs y eso en la mayoría de ocasiones suele ser un problema ya que al crear una aplicación, OpenShift utiliza DeploymentConfigs.
En OpenShift el criterio es ... ¿Quiero usar GitOps o los procedimientos que me ofrece RedHat para la gestión de Kubernetes?

• Si mi elección es usar las herramientas que ofrece Redhat, Terraform está fuera de lugar.
• Si mi elección es usar GitOps o me hago un script que me lo haga tal como hice yo hace un par de años en python, o utilizo Terraform con sus limitaciones.

Yo llevo apostando por GitOps desde antes que alguien le diera nombre.