kube-exam/helm/README.md

Decisiones de diseño del chart Helm

Introducción

Este readme explica algunas de las decisiones de diseño tomadas durante el desarrollo del chart Helm. El objetivo es proporcionar información sobre las razones detrás de ciertas configuraciones en el archivo values.yaml.

Valores predeterminados para eliminar redundancias

Configuración del servicio

En el archivo service.yaml, se han establecido valores predeterminados para ciertos parámetros, como type y targetPort. Por ejemplo, el type se establece en "ClusterIP" de forma predeterminada, y targetPort se establece en $port.

Beneficios:

1. Eliminación de redundancias: Los valores predeterminados reducen la redundancia en el archivo values.yaml. Los usuarios pueden centrarse en personalizar valores específicos de su implementación.

2. Flexibilidad: Los usuarios tienen la libertad de modificar estos valores predeterminados en el archivo values.yaml sin necesidad de especificarlos explícitamente para cada servicio. Por ejemplo, cambiar el type a "NodePort" para el servicio api es tan simple como actualizar values.yaml.

services:
    - api:
    name: "api"
    tier: "backend"
    port: 5000
    type: "NodePort"

Configuración de Ingress para flexibilidad de dominio

En el archivo ingress.yaml, el campo host se repite para cada ruta. Esta elección de diseño permite la flexibilidad de alojar la API en un dominio diferente si así se desea.

ingress:
  ssl: true
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
  hosts:
    - host: kube.slc.ar
      paths:
        - path: /
          name: "client"
          port: 8080
          pathType: "Prefix"
    - host: api.kube.slc.ar
      paths:
        - path: /
          name: "api"
          port: 5000
          pathType: "Prefix"
  tls:
   - secretName: exam-crt
     hosts:
       - kube.slc.ar
       - api.kube.slc.ar

Beneficio:

• Flexibilidad de dominio: La repetición del campo host en cada ruta proporciona la flexibilidad de alojar la API en un dominio diferente (api.kube.slc.ar en este ejemplo). Los usuarios pueden personalizar fácilmente la sección hosts en el archivo values.yaml según sus requisitos de dominio específicos.

Estas elecciones de diseño buscan simplificar la gestión de la configuración, reducir la redundancia y proporcionar a los usuarios la flexibilidad de adaptar el chart Helm a sus necesidades de implementación.

---

Todas las variables que se repiten y que, en un principio, no tendría sentido cambiarlas para este chart se marcaron con default.

Por ejemplo, busque los default de service.yaml. Verá que type es por defecto "ClusterIP" y que targetPort es por defecto $port.

Esto tiene dos beneficios:

1. Elimina redundancia en values.yaml
2. Da libertad para que en un futuro se pueda simplemente modificarlo en values.yaml. Por ejemplo, supongamos que queremos cambiar el type a "NodePort" en el servicio de api, basta con hacer el siguiente cambio:

services:
  - api:
    name: "api"
    tier: "backend"
    port: 5000
    type: "NodePort"

---

En ingress se repite el host debido a facilita que la api pueda estar en otro dominio, si así se desea:

ingress:
  ssl: true
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
  hosts:
    - host: kube.slc.ar
      paths:
        - path: /
          name: "client"
          port: 8080
          pathType: "Prefix"
    - host: api.kube.slc.ar
        - path: /
          name: "api"
          port: 5000
          pathType: "Prefix"
  tls:
   - secretName: exam-crt
     hosts:
       - kube.slc.ar
       - api.kube.slc.ar

---

Se puede pasar certificados autogenerados en ingress.ssl.* PERO se debe notar las restricciones de helm de seguridad: solo se pueden usar archivos relativos al path del chart. Por lo tanto, si se desea usar un archivo de "afuera" se puede hacer un symbolic link. Por ejemplo: cd helm && ln -sf /usr/local/etc/ssl/certs/ca.crt ca.crt && ln -sf /usr/local/etc/ssl/private/ca.key ca.key. Y luego se puede pasar esos archivos al ingress.ssl.*.

Note que para que se usen estos secrets:

1. si ya existía el secret-crt se debe borrar y hacer un helm upgrade
2. si no existía con un install basta (o mismo un upgrade si ya estaba andando)

Por lo tanto, supongamos que se quieren actualizar los certificados por unos autogenerados por usted (y para actualizarlos una vez expirados los autogenerados por usted). Los pasos son los siguientes:

1. Borrar exam-crt
2. Actualizar certificados
3. Ponerlos en el values.yaml de haberse modificado el path o si antes se usaba uno autogenerado por helm
4. Hacer upgrade

Si se quiere actualizar los autogenerados por helm los pasos son:

1. Borrar exam-crt
2. Hacer upgrade

Note que si se hace un upgrade solo NO se regenerará el exam-crt. Esto es esperado ya que sino cada vez que modificamos algo se estará autogenerando un nuevo certificado!!