Configuring Networking (Ingress)
Relevant source files
The following files were used as context for generating this wiki page:
Networking configuration, specifically for exposing services to external traffic, is a critical aspect of deploying applications within this repository. This is primarily managed using Kubernetes Ingress resources, which are defined and configured through the ingress section in each chart's values.yaml file. This allows for a standardized way to control external access, set hostnames, and manage TLS termination across different applications like agh2, agh3, hoppscotch, and playground.
The configuration is flexible, allowing operators to enable or disable ingress on a per-chart basis, specify the fully qualified domain name for access, and secure the connection using TLS certificates. The implementation relies on standard Kubernetes Ingress objects, making it compatible with most ingress controllers.
Core Ingress Configuration
The primary mechanism for configuring ingress is the ingress object within each chart's values.yaml file. While some charts may have slight variations, the core parameters are consistent.
Sources: charts/agh3/values.yaml:120-122, charts/agh2/values.yaml:68-70, charts/playground/values.yaml:49-51
Common Parameters
The following table outlines the most common ingress configuration parameters found across the charts.
| Parameter | Type | Description | Default Value (agh3) |
|---|---|---|---|
ingress.enabled | Boolean | Toggles the creation of the Ingress resource. | true |
ingress.host | String | The hostname to be used for the ingress rule. | app.argushack.com |
Sources: charts/agh3/values.yaml:120-122, charts/agh2/README.md, charts/playground/README.md
A typical configuration block in values.yaml looks like this:
ingress:
enabled: true
host: app.argushack.com
Sources: charts/agh3/values.yaml:120-122
Ingress Resource Definition
The Helm charts generate standard Kubernetes Ingress resources when ingress.enabled is set to true. The hoppscotch chart provides a clear example of how these values are translated into a manifest file.
This diagram illustrates the request flow from a user to the application pod via the Ingress resource.
The template uses values for hostname, path, and the backend service to route traffic. Annotations can also be added to customize the behavior of the specific ingress controller being used.
# charts/hoppscotch/templates/ingress.yaml
{{- if .Values.ingress.enabled }}
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: {{ .Release.Name }}-app-ingress
annotations:
{{- with .Values.ingress.annotations }}
{{ toYaml . | indent 4 }}
{{- end }}
spec:
rules:
- host: {{ .Values.ingress.hostname }}
http:
paths:
- path: {{ .Values.ingress.path }}
pathType: Prefix
backend:
service:
name: {{ .Release.Name }}-aio
port:
number: 3000
{{- if .Values.ingress.tls.enabled }}
tls:
- hosts:
- {{ .Values.ingress.hostname }}
secretName: {{ .Values.ingress.tls.secretName }}
{{- end }}
{{- end }}
Sources: charts/hoppscotch/templates/ingress.yaml:1-26
TLS Configuration
TLS can be enabled to secure traffic to the application. The configuration is managed under the ingress.tls key.
TLS Parameters
| Parameter | Type | Description | Default Value (agh3) |
|---|---|---|---|
ingress.tls.enabled | Boolean | Enables or disables TLS for the ingress. | false |
ingress.tls.secretName | String | The name of the Kubernetes secret containing the TLS certificate and key. | agh-tls |
ingress.tls.cert | String | The server certificate content (Base64 encoded or plain text). | (example cert) |
ingress.tls.key | String | The server private key content. | "" |
Sources: charts/agh3/values.yaml:123-132, charts/agh2/values.yaml:74-83, charts/playground/values.yaml:54-62
When ingress.tls.enabled is true, a tls block is added to the Ingress spec, which tells the ingress controller to terminate TLS using the specified secret.
This diagram shows the logic for enabling TLS and the associated validation.
Configuration Validation
The agh3 chart includes a validation step to ensure that if TLS is enabled, the required certificate and key are provided in values.yaml. If ingress.tls.enabled is true but cert or key are empty, the Helm installation will fail with an error message.
# charts/agh3/templates/validations/index.yaml
{{- if .Values.ingress.tls.enabled -}}
{{- $errorMsg = printf "%s\n%s"
$errorMsg
(
include "validations.required" (
dict
"path" "ingress.tls"
"fields" (list "cert" "key")
"msg" "Must provide when ingress.tls.enabled is true"
"context" $
)
)
-}}
{{- end -}}
Sources: charts/agh3/templates/validations/index.yaml:25-36
Chart-Specific Implementations
agh2 and agh3 Charts
Both agh2 and agh3 charts provide a comprehensive ingress configuration block.
agh3: Defaults toapp.argushack.comas the host.agh2: Thehostvalue is empty by default and must be provided by the user.
Both charts include an example certificate under ingress.tls.cert but leave ingress.tls.enabled as false by default, requiring users to explicitly enable it and provide a valid key.
Sources: charts/agh2/values.yaml:68-84, charts/agh3/values.yaml:120-132
playground Chart
The playground chart follows a similar pattern for its ingress and ingress.tls configuration. It is designed to expose the playground frontend service. The deployment for the playground container uses an environment variable API_ENDPOINT which is constructed based on service discovery, indicating it communicates with a backend API that would typically be exposed via the same ingress host but on a different path.
Sources: charts/playground/values.yaml:49-63, charts/playground/templates/playground-deployment.yml:19-21