Add Blog Post for Envfiles

Author: HirazawaUi

content/en/blog/_posts/2025-09-01-introducing-env-files/index.md

@@ -0,0 +1,84 @@
+---
+layout: blog
+title: "Kubernetes v1.34: Use An Init Container To Define App Environment Variables"
+date: 2025-0X-XX
+draft: true
+slug: kubernetes-v1-34-env-files
+author: >
+  HirazawaUi
+---
+
+Kubernetes typically uses ConfigMaps and Secrets to set environment variables,
+which introduces additional API calls and complexity,
+For example, you need to separately manage the Pods of your workloads 
+and their configurations, while ensuring orderly 
+updates for both the configurations and the workload Pods.
+
+Alternatively, you might be using a vendor-supplied container 
+that requires environment variables (such as a license key or a one-time token),
+but you don’t want to hard-code them or mount volumes just to get the job done.
+
+If that's the situation you are in, you now have a new (alpha) way to
+achieve that. Provided you have the `EnvFiles`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+enabled across your cluster, you can tell the kubelet to load a container's
+environment variables from a volume (the volume must be part of the Pod that
+the container belongs to).
+this feature gate allows you to load environment variables directly from a file in an emptyDir volume
+without actually mounting that file into the container.
+It’s a simple yet elegant solution to some surprisingly common problems.
+
+## What’s this all about?
+At its core, this feature allows you to point your container to a file,
+one generated by an `initContainer`,
+and have Kubernetes parse that file to set your environment variables.
+The file lives in an `emptyDir` volume (a temporary storage space that lasts as long as the pod does),
+Your main container doesn’t need to mount the volume.
+The kubelet will read the file and inject these variables when the container starts.
+
+## How It Works
+Here's a simple example:
+```yaml
+apiVersion: v1
+kind: Pod
+spec:
+  initContainers:
+  - name: generate-config
+    image: busybox
+    command: ['sh', '-c', 'echo "CONFIG_VAR=HELLO" > /config/config.env']
+    volumeMounts:
+    - name: config-volume
+      mountPath: /config
+  containers:
+  - name: app-container
+    image: gcr.io/distroless/static
+    env:
+    - name: CONFIG_VAR
+      valueFrom:
+        fileKeyRef:
+          path: config.env
+          volumeName: config-volume
+          key: CONFIG_VAR
+  volumes:
+  - name: config-volume
+    emptyDir: {}
+```
+
+Using this approach is a breeze.
+You define your environment variables in the pod spec using the `fileKeyRef` field,
+which tells Kubernetes where to find the file and which key to pull.
+The file itself follows the de-facto standard for `.env` syntax (think `KEY=VALUE`),
+and (for this alpha stage at least) you must ensure that it is written into
+an `emptyDir` volume. Other volume types aren't supported for this feature.
+At least one init container must mount that `emptyDir` volume (to write the file),
+but the main container doesn’t need to—it just gets the variables handed to it at startup.
+
+## A word on security
+While this feature supports handling sensitive data such as keys or tokens, 
+note that its implementation relies on `emptyDir` volumes mounted into pod.
+Operators with node filesystem access could therefore 
+easily retrieve this sensitive data through pod directory paths.
+
+If storing sensitive data like keys or tokens using this feature,
+ensure your cluster security policies effectively protect nodes
+against unauthorized access to prevent exposure of confidential information.