Kustomize - Create multi and single deployment using same namespace - kubernetes

Kustomize directory structure
├── base
│   ├── deployment.yaml
│   └── kustomization.yaml
└── overlays
└── prod
├── kustomization.yaml
├── namespace-a
│   ├── deployment-a1
│   │   ├── kustomization.yaml
│   │   └── patch.yaml
│   ├── deployment-a2
│   │   ├── kustomization.yaml
│   │   └── patch.yaml
│   ├── kustomization.yaml
│   └── namespace.yaml
├── namespace-b
│   ├── deployment-b1
│   │   ├── kustomization.yaml
│   │   └── patch.yaml
│   ├── deployment-b2
│   │   ├── kustomization.yaml
│   │   └── patch.yaml
│   ├── kustomization.yaml
│   └── namespace.yaml
└── namespace-c
As you can see above, I have prod environment with namesapce-a and namespace-b and few more.
To create deployment for all, I can simply run the below command:
> kustomize overlays/prod
Which works flawlessly, both namespaces are created along with other deployment files for all deployments.
To create a deployment for only namespace-a:
> kustomize overlays/prod/namespace-a
That also works. :)
But that's not where the story ends for me at-least.
I would like to keep the current functionality and be able to deploy deployment-a1, deployment-a2 ...
> kustomize overlays/prod/namespace-a/deployment-a1
If I put the namespace.yaml inside deployment-a1 folder and add it in kustomization.yaml
then the above command works but previous 2 fails with error because now we have 2 namespace files with same name.
I have 2 queries.
Can this directory structure be improved?
How can I create namesapce with single deployment without breaking the other functionality?
Full code can be seen here

In your particular case, in the most ideal scenario, all the required namespaces should already be created before running the kustomize command.
However, I know that you would like to create namespaces dynamically as needed.
Using a Bash script as some kind of wrapper can definitely help with this approach, but I'm not sure if you want to use this.
Below, I'll show you how this can work, and you can choose if it's right for you.
First, I created a kustomize-wrapper script that requires two arguments:
The name of the Namespace you want to use.
Path to the directory containing the kustomization.yaml file.
kustomize-wrapper.sh
$ cat kustomize-wrapper.sh
#!/bin/bash
if [ -z "$1" ] || [ -z "$2" ]; then
echo "Pass required arguments !"
echo "Usage: $0 NAMESPACE KUSTOMIZE_PATH"
exit 1
else
NAMESPACE=$1
KUSTOMIZE_PATH=$2
fi
echo "Creating namespace"
sed -i "s/name:.*/name: ${NAMESPACE}/" namespace.yaml
kubectl apply -f namespace.yaml
echo "Setting namespace: ${NAMESPACE} in the kustomization.yaml file"
sed -i "s/namespace:.*/namespace: ${NAMESPACE}/" base/kustomization.yaml
echo "Deploying resources in the ${NAMESPACE}"
kustomize build ${KUSTOMIZE_PATH} | kubectl apply -f -
As you can see, this script creates a namespace using the namespace.yaml file as the template. It then sets the same namespace in the base/kustomization.yaml file and finally runs the kustomize command with the path you provided as the second argument.
namespace.yaml
$ cat namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
name:
base/kustomization.yaml
$ cat base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace:
resources:
- deployment.yaml
Directory structure
$ tree
.
├── base
│ ├── deployment.yaml
│ └── kustomization.yaml
├── kustomize-wrapper.sh
├── namespace.yaml
└── overlays
└── prod
├── deployment-a1
│ ├── kustomization.yaml
│ └── patch.yaml
├── deployment-a2
│ ├── kustomization.yaml
│ └── patch.yaml
└── kustomization.yaml
We can check if it works as expected.
Creating the namespace-a Namespace along with app-deployment-a1 and app-deployment-a2 Deployments:
$ ./kustomize-wrapper.sh namespace-a overlays/prod
Creating namespace
namespace/namespace-a created
Setting namespace: namespace-a in the kustomization.yaml file
deployment.apps/app-deployment-a1 created
deployment.apps/app-deployment-a2 created
Creating only the namespace-a Namespace and app-deployment-a1 Deployment:
$ ./kustomize-wrapper.sh namespace-a overlays/prod/deployment-a1
Creating namespace
namespace/namespace-a created
Setting namespace: namespace-a in the kustomization.yaml file
deployment.apps/app-deployment-a1 created

Related

kustomize on Ingress on kubernetes (minikube) cluster

i did with success some kustomize for multi-evironnements
on a files tree like :
├── base
│   ├── deployment.yaml
│   ├── kustomization.yaml
│   ├── service.yaml
├── overlays
│   ├── prod
│   │   ├── application.properties
│   │   ├── kustomization.yaml
│   └── uat
│   ├── application.properties
│   ├── kustomization.yaml
but id'like to add now auto generation of an ingress ressource,
in a tree similar as..
├── base
│   ├── deployment.yaml
│   ├── kustomization.yaml
│   ├── service.yaml
│   ├── ingress.yaml <============ added template
├── overlays
│   ├── prod
│   │   ├── application.properties
│   │   ├── kustomization.yaml
│   └── uat
│   ├── application.properties
│   ├── kustomization.yaml
Is it possible ?
Does anybody has a snippet or tricks to do that ?
in my prod overlay, my kustomization.yaml file is :
bases:
- ../../base
namespace: prod
patches:
- replicas.yaml
configMapGenerator:
- name: application.properties
files:
- application.properties=application.properties
but when i launch my command
kubectl apply -k .
it does not create my Ingress ressource (only configmap, service and deployment)
So: how does it work ?

Flux v2 - How to Deploy Same Helm Chart, Multiple Times, Into Different Namespaces

We are building out a small cluster for a dev team.
Ive been working through this repo: https://github.com/fluxcd/flux2-kustomize-helm-example
The infrastructure part went fine.
Now instead of apps I need to create a way for each developer, to deploy/maintain their own version of the application they are working on.
├── clusters
│   └── qa
│   ├── deploys.bak
│   ├── flux-system
│   │   ├── gotk-components.yaml
│   │   ├── gotk-sync.yaml
│   │   └── kustomization.yaml
│   └── infrastructure.yaml
├── deploys
│   ├── base
│   ├── dev1
│   ├── dev2
│   ├── dev3
│   └── staging
In deploys/base it would be great to specify a Namespace, a HelmRelease, and a Kubernetes Secret.
Then in deploys/dev1 it would be great if we could include the base but have a way of overriding the namespace everything goes into.
So you would have namespaces app-dev1, app-dev2 etc.
This would allow us to only really have to override the ingress information, and the image tag for the app.
Thanks for any information on this.
You need to add a patch to your kustomization.
patches:
- target:
kind: HelmRelease
name: .*-helm-release
version: v2beta1
patch: |-
- op: add
path: /spec/targetNamespace
value: dev1
- op: replace
path: /metadata/namespace
value: dev1
Add this to every env that you want.

Helm: use packaged values.dev.yaml for install

Given the chart structure:
└── myChart
├── Chart.yaml
├── templates
│   ├── ...
│   └── service.yaml
├── values.dev.yaml
└── values.yaml
values.dev.yaml gets packaged with the chart.tgz. Is it possible to use values.dev.yaml for values (-f) when installing ?

Helmfile how change exist resource to another chart

I want to move official-web this chart in sw-api chart template to independent chart,and move the files out off the sw-api's template
then use helmfile apply ,give me this error.
This is my error code
Error: Failed to render chart: exit status 1:
Error: rendered manifests contain a resource that already exists.
Unable to continue with install: ConfigMap "official-web-config" in namespace "develop" exists and cannot be imported into the current release: invalid ownership metadata;
annotation validation error: key "meta.helm.sh/release-name" must equal "official-web": current value is "sw-api"
This my helm folder now
── sw-api
│   ├── Chart.yaml
│   ├── templates
│   │   ├── micros-worker
│   │   │   ├── configMap.yaml
│   │   │   ├── deployment.yaml
│   │   │   └── hpa.yaml
│   │   └── official-web
│   │   ├── certificate.yaml
│   │   ├── configMap.yaml
│   │   ├── deployment.yaml
│   │   ├── hpa.yaml
│   │   ├── ingress.yaml
│   │   ├── ip.yaml
│   │   └── svc.yaml
│   ├── values-dev.yaml
├── sw-api-values.yaml.gotmpl
── swagger
│   ├── Chart.yaml
│   ├── templates
│   │   ├── _helpers.tpl
│   │   ├── deployment.yaml
│   │   └── svc.yaml
│   ├── values-dev.yaml
I become like this
── official-web
│   ├── Chart.yaml
│   ├── templates
│   │   ├── _helpers.tpl
│   │   ├── certificate.yaml
│   │   ├── configMap.yaml
│   │   ├── deployment.yaml
│   │   ├── hpa.yaml
│   │   ├── ingress.yaml
│   │   ├── ip.yaml
│   │   └── svc.yaml
│   ├── values-dev.yaml
├── official-web-values.yaml.gotmpl
├── sw-api
│   ├── Chart.yaml
│   │   └── micros-worker
│   │   ├── configMap.yaml
│   │   ├── deployment.yaml
│   │   └── hpa.yaml
│   ├── values-dev.yaml
│   └── values-test.yaml
├── sw-api-values.yaml.gotmpl
And do helmfile apply command (in namespace "develop"):
helmfile -f helmfile.yaml --log-level=debug --debug -e dev apply
This error show before do hemlfile apply
Error: Failed to render chart: exit status 1:
Error: rendered manifests contain a resource that already exists.
Unable to continue with install: ConfigMap "official-web-config" in namespace "develop" exists and cannot be imported into the current release: invalid ownership metadata;
annotation validation error: key "meta.helm.sh/release-name" must equal "official-web": current value is "sw-api"

referring a resource yaml from another directory in kustomization

I have a resource yaml file in a folder structure given below
base
---- first.yaml
main
---- kustomization.yaml
In kustomization.yaml I am referring the first.yaml as
resources:
../base/first.yaml
But I am getting an error when i do apply of kubectl apply -f kustomizatio.yaml
accumulating resources: accumulating resources from '../base/first.yaml': security; file '../base/first.yaml' is not in or below '../base'
How can i call the first.yaml resource from the folder base to the kustomization in main folder?
Kustomize cannot refer to individual resources in parent directories, it can only refer to resources in current or child directories, but it can refer to other Kustomize directories.
The following would be a valid configuration for what you have:
.
├── base
│   ├── main
│   │   ├── kustomization.yaml
│   │   └── resource.yaml
│   └── stuff
│   ├── first.yaml
│   └── kustomization.yaml
└── cluster
└── kustomization.yaml
Contents of base/main/kustomization.yaml:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- resource.yaml
Contents of base/stuff/kustomization.yaml:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- first.yaml
Contents of cluster/kustomization.yaml:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../base/main
- ../base/stuff
Run kustomize build from one folder down, kustomize build ./main. You aren't allowed to .. up past where kustomize started from, just to be safe.