3.7 KiB
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:
-
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. -
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 eltype
a "NodePort" para el servicioapi
es tan simple como actualizarvalues.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ónhosts
en el archivovalues.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:
- Elimina redundancia en values.yaml
- Da libertad para que en un futuro se pueda simplemente modificarlo en
values.yaml
. Por ejemplo, supongamos que queremos cambiar eltype
a "NodePort" en el servicio deapi
, 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