master
lza_menace 4 years ago
commit 58a30358b6

@ -0,0 +1 @@
kustomize

@ -0,0 +1,72 @@
# Kustomize Example
The intention of this repo is to showcase some of the capabilities of Kustomize. I have adapted one of the examples from the Kustomize Github repo; the rest can be found here: https://github.com/kubernetes-sigs/kustomize/tree/master/examples
## Bases vs Overlays
### Bases
When you run `kustomize` the "base" is loaded into memory and if any "overlays" exist that match they are merged over top of your "base" configuration. The "base" is the core module which defines the container infrastructure and their properties.
In this example, my base consists solely of the "hello" Golang application and Kubernetes objects for deployment, service, and configmap.
```
base
├── hello
│   ├── configMap.yaml
│   ├── deployment.yaml
│   ├── kustomization.yaml
│   └── service.yaml
└── kustomization.yaml
```
I could deploy this as-is to a cluster by running `kustomize build base | kubectl apply -f -`, but I would miss out on being able to make minor adjustments to account for variances between environments. Maybe you want labels to reflect the environment it's running in; maybe things should be in a different namespace; maybe you want different environment variables or secrets.
Enter overlays.
### Overlays
Overlays are where you can make those minor adjustments that build upon the base. In this example I've setup overlays for each environment, though I've seen them used for particular clusters or namespaces; use it however makes the most sense.
```
overlays
├── production
│   ├── deployment.yaml
│   └── kustomization.yaml
└── staging
├── kustomization.yaml
└── map.yaml
```
#### Staging
For the [staging overlay](overlays/staging/kustomization.yaml) I'm adjusting the labels and annotations to reflect the staging environment. Also, I'm using a different configmap for the "hello" application whch is referenced in the base deployment; this will reflect in the output when reaching the service at the load balancer via HTTP.
Now I can apply staging specific resources to my cluster by running `kustomize build overlays/staging | kubectl apply -f -`. Compare the diffs between the rendered base and rendered staging overlay:
![](images/diff_staging_base.png)
#### Production
For the [production overlay](overlays/production/kustomization.yaml) I'm adjusting the labels and annotations as well as bumping deployment replicas and injecting a new environment variable.
Apply it with `kustomize build overlays/production | kubectl apply -f -`. Now compare the diffs between rendered base and rendered production overlay:
![](images/diff_production_base.png)
#### Staging vs Production
Finally, comparing diffs between staging and production helps to see the differences between them.
![](images/diff_production_staging.png)
# Further Reading
I found these links helpful in my evaluation of tooling which ultimately lead to my recommendations:
* :fire: https://stackoverflow.com/questions/60519939/what-is-the-difference-between-helm-and-kustomize
* :fire: https://argoproj.github.io/argo-cd/user-guide/best_practices/
* https://foghornconsulting.com/2020/06/04/helm-versus-kustomize/#:~:text=To%20boil%20it%20all%20down,anything%20in%20a%20Kubernetes%20manifest
* https://medium.com/@alexander.hungenberg/helm-vs-kustomize-how-to-deploy-your-applications-in-2020-67f4d104da69
* https://luktom.net/en/e1683-argocd-vs-flux#:~:text=The%20basic%20features%20are%20the,git%20repositories%20to%20one%20cluster
* https://blog.container-solutions.com/fluxcd-argocd-or-jenkins-x-which-is-the-right-gitops-tool-for-you

@ -0,0 +1,7 @@
apiVersion: v1
kind: ConfigMap
metadata:
name: the-map
data:
altGreeting: "Good Morning!"
enableRisky: "false"

@ -0,0 +1,33 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: the-deployment
spec:
replicas: 1
selector:
matchLabels:
deployment: hello
template:
metadata:
labels:
deployment: hello
spec:
containers:
- name: the-container
image: monopole/hello:1
command: ["/hello",
"--port=8080",
"--enableRiskyFeature=$(ENABLE_RISKY)"]
ports:
- containerPort: 8080
env:
- name: ALT_GREETING
valueFrom:
configMapKeyRef:
name: the-map
key: altGreeting
- name: ENABLE_RISKY
valueFrom:
configMapKeyRef:
name: the-map
key: enableRisky

@ -0,0 +1,9 @@
# Example configuration for the webserver
# at https://github.com/monopole/hello
commonLabels:
app: hello
resources:
- deployment.yaml
- service.yaml
- configMap.yaml

@ -0,0 +1,12 @@
kind: Service
apiVersion: v1
metadata:
name: the-service
spec:
selector:
deployment: hello
type: LoadBalancer
ports:
- protocol: TCP
port: 80
targetPort: 8080

@ -0,0 +1,2 @@
bases:
- ./hello

Binary file not shown.

After

Width:  |  Height:  |  Size: 660 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 594 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 649 KiB

@ -0,0 +1,13 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: the-deployment
spec:
replicas: 5
template:
spec:
containers:
- name: the-container
env:
- name: MY_NEW_VAR
value: Value defined by Kustomize for production overlay

@ -0,0 +1,10 @@
namePrefix: production-
commonLabels:
variant: production
org: acmeCorporation
commonAnnotations:
note: Hello, I am production!
bases:
- ../../base
patchesStrategicMerge:
- deployment.yaml

@ -0,0 +1,7 @@
apiVersion: v1
kind: ConfigMap
metadata:
name: the-map
data:
altGreeting: "Have a pineapple!"
enableRisky: "true"

@ -0,0 +1,10 @@
namePrefix: staging-
commonLabels:
variant: staging
org: acmeCorporation
commonAnnotations:
note: Hello, I am staging!
bases:
- ../../base
patchesStrategicMerge:
- configmap.yaml
Loading…
Cancel
Save