Teymur Gahramanov teymurgahramanov

With these named templates you can ensure the same metadata (resource name, namespace, labels, annotations) across all templates in your Helm chart. It is also can be used inside range loops.

Examples:

In ingress.yaml there is an example of using common.metadata template without extra argument.
In vault-secrets.yaml there is a more complex example of using common.metadata, and resource.name templates inside loop by passing $key for generating VaultAuth and VaultStaticSecret for each key name in the values file.

Prometheus alerts based on resource labels via Alertmanager

Assume that you have several development teams which are work on the same Kubernetes cluster and each team need to get alerts only related to their projects. For example, team "A" should only get alerts if there are any unhealthy pods with labels team: A and app: app1 or app: app2

Requirements:

Appropriate labels on your pods
kube-state-metrics (tested with 2.4.2 version) with argument --metric-labels-allowlist=pods=[*]
Prometheus job for pods
Prometheus rule which will join pod labels from kube_pod_labels to metric e.g.

Solution of empty database problem after gitlab-ctl pg-upgrade

Сase:

Unable to upgrade GitLab 13.X.X (Linux package) to 14.X.X because it does not support PostgreSQL version less than 12 (Current 11). Tried to upgrade PostgreSQL using gitlab-ctl pg-upgrade -V 12 as described in Upgrade packaged PostgreSQL server.

Expected behavior

This updates PostgreSQL to the default shipped version during package upgrades, unless specifically opted out.

Current behavior

gitlab-ctl pg-upgrade -V 12 finishes successfully but ends with an empty database and GitLab acts as if a fresh install.

Dynamic HTML Table with Jinja2

The Jinja2 template snippet for generating HTML table, based on data retrieved from the database.

In this example, assumed that we have two lists:

db_data_columns for columns
db_data_rows for rows

Kubernetes dynamic secret for Image Registry using Helm and Gitlab

Instead of manually creating secret for pulling images from Image Registry we can generate it using variables during pipeline.

For example assume that:

your template for secret is as example-helm-secret-template.yaml
you have $DOCKER_USER $DOCKER_PASSWORD variables.
you are using Gitlab Container Registry

Just add this override to helm install command:

Ansible change password of current user on fly

You also can change other connection parameters in this way during playbook execution.

Ansible handler to reload and check systemd's service status

	for pv in $(kubectl get pv -o custom-columns="NAME:.metadata.name" --no-headers); do
	GLUSTERFS_PATH=$(kubectl get pv -A $pv -o yaml \| yq .spec.glusterfs.path)
	PVC_NAME=$(kubectl get pv $pv -o yaml \| yq .spec.claimRef.name)
	USED_BY=()
	for chart in $(kubectl get deployments --all-namespaces -o=json \| \
	jq --arg pvc "$PVC_NAME" -r '.items[] \| select(.spec.template.spec.volumes[]?.persistentVolumeClaim.claimName == $pvc) \| .metadata.annotations."meta.helm.sh/release-name"'); do
	USED_BY+=($chart)
	done
	echo "$GLUSTERFS_PATH,$PVC_NAME,${USED_BY[*]}"
	done

	# Make a copy of your kubeconfig file:
	cp ~/.kube/config ~/.kube/config-backup

	# Create files with your contexts, like ~/.kube/cluster-1 ~/.kube/cluster-2 ... And create KUBECONFIG env variable:
	export KUBECONFIG=~/.kube/:$(find ~/.kube -maxdepth 1 -type f \| tr '\n' ':')

	# Create new ~/.kube/config
	kubectl config view --flatten > ~/.kube/config

	# Verify