If you’re running Windows-based applications on Kubernetes, using ConfigMaps to manage startup scripts ensures consistency, scalability, and easier configuration management. This guide walks you through the process of creating a ConfigMap for a startup script and executing it in a Windows container,

What is a ConfigMap?

A ConfigMap is a Kubernetes object used to store non-confidential configuration data in key-value pairs. It decouples configuration artifacts from container images, making applications portable and easier to manage. ConfigMaps can store:

• Configuration files (e.g., JSON, XML, YAML).
• Environment variables.
• Scripts (e.g., startup scripts).

Use Cases for ConfigMaps

ConfigMaps are ideal for:

• Storing Application Configuration: Manage settings like database URLs, API endpoints, or feature flags.
• Injecting Environment Variables: Pass runtime configurations to containers.
• Managing Startup Scripts: Execute initialization logic during container startup.
• Sharing Configuration Across Pods: Reuse the same configuration for multiple deployments.

When and Where to Use ConfigMaps

Use ConfigMaps when:

• You need to externalize configuration from your container images.
• You want to avoid hardcoding sensitive or environment-specific data.
• You need to execute scripts during container initialization.
• You want to centralize configuration for multiple pods or services.
• ConfigMaps are particularly useful in Windows-based Kubernetes deployments where PowerShell scripts are commonly used for setup and initialization.

Step 1: Create the Startup Script

Start by writing a PowerShell script (startup.ps1) for your Windows container. For example:

Write-Host "Starting application setup..."
# Your setup commands here
Start-Sleep -Seconds 5
Write-Host "Application is ready!"

Step 2: Create a ConfigMap from the Script

Next, create a ConfigMap from your startup script file. Use the kubectl create configmap command to generate a ConfigMap that includes your PowerShell script.

This command reads the startup.ps1 file and creates a ConfigMap named win-startup-script.

kubectl create configmap [configmap_name] --from-file [path/to/yaml/file]

kubectl create configmap win-startup-script --from-file=startup.ps1

To verify the config map is correctly created with script, you can use the command kubectl describe configmap win-startup-script to retrieve detailed information about a specific ConfigMap named win-startup-script in your Kubernetes cluster. This command is particularly useful for debugging, verifying configurations, or understanding how a ConfigMap is structured.

kubectl describe configmap <configmap-name>

kubectl describe configmap win-startup-script

Step 3: Mount the ConfigMap in Your Deployment

Create a deployment manifest for your Windows container. In your YAML file, reference the ConfigMap so that the startup script is available to your container.

Modify your Kubernetes deployment YAML to:

1. Mount the ConfigMap as a volume.
2. Execute the script on container startup.

Example deployment.yaml:

apiVersion: apps/v1  
kind: Deployment  
metadata:  
  name: windows-app  
spec:  
  replicas: 1  
  selector:  
    matchLabels:  
      app: windows-app  
  template:  
    metadata:  
      labels:  
        app: windows-app  
    spec:  
      containers:  
      - name: windows-container  
        image: mcr.microsoft.com/windows/servercore:ltsc2019  
        command: ["powershell", "-Command", "C:\\scripts\\startup.ps1"]  
        volumeMounts:  
        - name: startup-script-volume  
          mountPath: "C:\\scripts"  
          readOnly: true  
      volumes:  
      - name: startup-script-volume  
        configMap:  
          name: win-startup-script  
      nodeSelector:  
        kubernetes.io/os: windows

How It Works

ConfigMap as a Volume:

• The ConfigMap win-startup-script contains a key-value pair where the key is startup.ps1 and the value is the script content.
• When the pod is created, the ConfigMap is mounted as a volume at C:\scripts inside the container.
• The script startup.ps1 becomes accessible at C:\scripts\startup.ps1

Script Execution:

• The command field in the container specification runs the PowerShell script at startup.
• The script executes the commands defined in startup.ps1, such as printing messages or performing setup tasks.
• The use of C:\\scripts (Windows-style path) and the mcr.microsoft.com/windows/servercore:ltsc2019 image ensures compatibility with Windows containers.

Step 4: Apply the Deployment

Deploy your application:

kubectl apply -f deployment.yaml

Step 5: Verify Execution

Check if the script ran successfully:

kubectl logs <pod-name>

kubectl logs windows-app-75b64f6568-gzcmv

Output:

[su_note note_color=”#d2f2fa” text_color=”#333333″ radius=”3″]Starting application setup…

Application is ready![/su_note]

Conclusion

Using ConfigMaps to manage startup scripts in Windows-based Kubernetes deployments is a powerful and efficient way to externalize configuration and ensure consistency across your applications. By following the steps outlined in this guide, you can:

• Decouple Configuration from Code: Store scripts and configuration data outside your container images, making your applications more portable and easier to manage.
• Automate Startup Tasks: Execute PowerShell scripts during container initialization to set up environments, configure settings, or perform other necessary tasks.
• Leverage Kubernetes Features: Use ConfigMaps as volumes to inject scripts into your containers, ensuring they are available at the correct location.
• Storing Application Configuration: Manage settings like database URLs, API endpoints, or feature flags.
• Injecting Environment Variables: Pass runtime configurations to containers without hardcoding them.
• Sharing Configuration Across Pods: Reuse the same configuration for multiple deployments, reducing duplication.
• Managing Configuration Files: Store and mount configuration files (e.g., JSON, XML, YAML) for applications that rely on external configs.

This approach not only simplifies configuration management but also enhances scalability and maintainability. Whether you’re running a single instance or scaling across multiple pods, ConfigMaps provide a centralized and reusable solution for managing startup scripts.

Question & Answer

Below are six frequently asked questions with concise answers based on the article:

1. What is a ConfigMap and why is it useful?
   A ConfigMap is a Kubernetes object that stores non-confidential configuration data as key-value pairs. It decouples configuration from container images, making applications more portable, easier to manage, and adaptable to different environments.

2. What are the common use cases for ConfigMaps?
   ConfigMaps are ideal for storing application configurations (e.g., database URLs, API endpoints, feature flags), injecting environment variables at runtime, managing startup or initialization scripts, and sharing configurations across multiple pods.

3. How do you create a startup script for a Windows container?
   You create a PowerShell script (e.g., startup.ps1) that contains the necessary initialization commands—such as logging messages or executing setup routines—which the Windows container will execute upon startup.

4. How do you generate a ConfigMap from a startup script?
   Use the kubectl create configmap command with the --from-file option. For example:
   kubectl create configmap win-startup-script --from-file=startup.ps1
   This command reads the script file and stores its content in a ConfigMap.

5. How do you mount a ConfigMap in your Windows container deployment?
   In your deployment YAML, define a volume that references the ConfigMap and mount it to a directory (e.g., C:\scripts) in your container. Then, specify the container’s command to execute the script from that location using PowerShell.

6. How can you verify that the ConfigMap and startup script are working correctly?
   After deploying your application, you can verify the ConfigMap with:
   kubectl describe configmap win-startup-script
   And check the container logs with:
   kubectl logs <pod-name>
   The logs should show output confirming that the startup script executed successfully (e.g., “Starting application setup…” and “Application is ready!”).