Every package Makefile tagged images via `settag` which, on a non-release commit, collapsed to `:latest`. Concurrent PR builds therefore raced on every image's `:latest` manifest in the OCIR registry. Two outliers (metallb, redis-operator) used hardcoded version tags and collided across PRs even when `settag` would not have. Replace `settag` and the `TAG=latest` fallback with an `image-tags` macro driven by three env vars: - IMAGE_TAG — build-unique tag, always pushed - PUBLISH_VERSIONED — also push :<component-version> - PUBLISH_FLOATING — also push :latest PR CI sets IMAGE_TAG=pr-<N>-<sha> with both PUBLISH_* off, so every push is unique across runs. Release CI sets IMAGE_TAG=<git-tag> with both PUBLISH_* on, preserving the previous release output and adding a uniform :<git-tag> tag across every image. Local builds default to IMAGE_TAG=dev with PUSH=0 already off. Image consumers reference digests pinned into values.yaml by each Makefile, so the tag is decorative for cluster-side pulls; the build-unique tag is sufficient for E2E. Drops the redundant `:<component-version>-<git-tag>` form (cilium, linstor, matchbox, ubuntu-container-disk, kubevirt-*, cluster-autoscaler) — nothing in the repo or downstream values.yaml consumed it. The same information is preserved via the new uniform `:<git-tag>` plus the existing `:<component-version>` on release. ubuntu-container-disk builds a separate image per Kubernetes version in a loop. Switched its primary tag to `:<k8s-ver>-<IMAGE_TAG>` so loop iterations within a single build do not push to the same tag. Assisted-By: Claude <noreply@anthropic.com> Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Managed Nginx-based HTTP Cache Service
The Nginx-based HTTP caching service is designed to optimize web traffic and enhance web application performance. This service combines custom-built Nginx instances with HAProxy for efficient caching and load balancing.
Deployment information
The Nginx instances include the following modules and features:
- VTS module for statistics
- Integration with ip2location
- Integration with ip2proxy
- Support for 51Degrees
- Cache purge functionality
HAproxy plays a vital role in this setup by directing incoming traffic to specific Nginx instances based on a consistent hash calculated from the URL. Each Nginx instance includes a Persistent Volume Claim (PVC) for storing cached content, ensuring fast and reliable access to frequently used resources.
Deployment Details
The deployment architecture is illustrated in the diagram below:
┌─────────┐
│ metallb │ arp announce
└────┬────┘
│
│
┌───────▼───────────────────────────┐
│ kubernetes service │ node
│ (externalTrafficPolicy: Local) │ level
└──────────┬────────────────────────┘
│
│
┌────▼────┐ ┌─────────┐
│ haproxy │ │ haproxy │ loadbalancer
│ (active)│ │ (backup)│ layer
└────┬────┘ └─────────┘
│
│ balance uri whole
│ hash-type consistent
┌──────┴──────┬──────────────┐
┌───▼───┐ ┌───▼───┐ ┌───▼───┐ caching
│ nginx │ │ nginx │ │ nginx │ layer
└───┬───┘ └───┬───┘ └───┬───┘
│ │ │
┌────┴───────┬─────┴────┬─────────┴──┐
│ │ │ │
┌───▼────┐ ┌────▼───┐ ┌───▼────┐ ┌────▼───┐
│ origin │ │ origin │ │ origin │ │ origin │
└────────┘ └────────┘ └────────┘ └────────┘
Known issues
- VTS module shows wrong upstream response time, github.com/vozlt/nginx-module-vts#198
Parameters
Common parameters
| Name | Description | Type | Value |
|---|---|---|---|
size |
Persistent Volume Claim size available for application data. | quantity |
10Gi |
storageClass |
StorageClass used to store the data. | string |
"" |
external |
Enable external access from outside the cluster. | bool |
false |
Application-specific parameters
| Name | Description | Type | Value |
|---|---|---|---|
endpoints |
Endpoints configuration, as a list of ip:port. | []string |
[] |
HAProxy parameters
| Name | Description | Type | Value |
|---|---|---|---|
haproxy |
HAProxy configuration. | object |
{} |
haproxy.replicas |
Number of HAProxy replicas. | int |
2 |
haproxy.resources |
Explicit CPU and memory configuration. When omitted, the preset defined in resourcesPreset is applied. |
object |
{} |
haproxy.resources.cpu |
CPU available to each replica. | quantity |
"" |
haproxy.resources.memory |
Memory (RAM) available to each replica. | quantity |
"" |
haproxy.resourcesPreset |
Default sizing preset used when resources is omitted. |
string |
t1.nano |
Nginx parameters
| Name | Description | Type | Value |
|---|---|---|---|
nginx |
Nginx configuration. | object |
{} |
nginx.replicas |
Number of Nginx replicas. | int |
2 |
nginx.resources |
Explicit CPU and memory configuration. When omitted, the preset defined in resourcesPreset is applied. |
object |
{} |
nginx.resources.cpu |
CPU available to each replica. | quantity |
"" |
nginx.resources.memory |
Memory (RAM) available to each replica. | quantity |
"" |
nginx.resourcesPreset |
Default sizing preset used when resources is omitted. |
string |
t1.nano |
Parameter examples and reference
resources and resourcesPreset
resources sets explicit CPU and memory configurations for each replica.
When left empty, the preset defined in resourcesPreset is applied.
resources:
cpu: 4000m
memory: 4Gi
resourcesPreset sets named CPU and memory configurations for each replica.
This setting is ignored if the corresponding resources value is set.
| Preset name | CPU | memory |
|---|---|---|
nano |
250m |
128Mi |
micro |
500m |
256Mi |
small |
1 |
512Mi |
medium |
1 |
1Gi |
large |
2 |
2Gi |
xlarge |
4 |
4Gi |
2xlarge |
8 |
8Gi |
endpoints
endpoints is a flat list of IP addresses:
endpoints:
- 10.100.3.1:80
- 10.100.3.11:80
- 10.100.3.2:80
- 10.100.3.12:80
- 10.100.3.3:80
- 10.100.3.13:80